What kinds of things would you want in the GNU OS?
news
What kinds of features or design rationale should it use?
For instance:
File system: SysV vs Berkeley? Something better?
Embedded file types? >32-bit file offsets?
Security: ACLs? Get rid of root? Security monitors? Auditing?
Provably secure(A1)?
Scheduler: Real-time support? Task-driven? Event driven?
Direct brain hookups:-)?
Virtual Memory: Should GNU run on non-VM machines? Algorithm ideas?
How general (map *everything* into VM space, like Multics)?
Shared libraries?
Networking: NFS? RFS? Something better?
Interfaces: Streams? TLI? Something better?
TCP/IP? OSI? SAA/SNA:-)?
RPC Services? What kind?
Overall Design: What nice ideas from other OSes could we use?
Multics? VMS? VM? DG/OS?
Fault tolerance?
How about this? Make everything a user process which serves
a resource to a client. Resources include the CPU (scheduler),
memory (VM), disk (file system), network (sockets, etc),
serial lines (terminal handlers), etc. Each server determines the access
method and security criteria for its service. Make no arbitrary policy
decisions regarding a service! Don't like the VM server? Replace it! You
could have a security monitor provide a security policy on behalf of
your file system or IPC mechanisms. If you have no need for security,
don't run the monitor.
Doug Gwyn
>What kinds of things should be in the GNU Kernel?
Why do you ask? Will this actually have an effect on the GNU kernel?
My opinion is that the GNU kernel should either provide an exact
duplicate of a standard UNIX system interface, preferably SVR4,
or it should be a quantum leap forward in OS design. The latter
will not be achieved by piling "features" into it.
Mike Haertel
No promises, but . . .
The major goal of the GNU project has been compatibility with Berkeley
UNIX, and then improvements. Now that POSIX is beginning to solidify,
we are taking that into account. So I think it's fairly safe to say
that we will be compatible with 4.3BSD (or perhaps 4.4, when it comes
out), and that we will be compatible with POSIX. System V is a secondary
concern, but we will probably try to be compatible with it insofar as
it does not conflict with higher priorities. Compatibility with any
of the above systems may be implemented at the library level rather
than the system call level. We intend to support the usual protocols,
like TCP/IP and NFS, but not necessarily in the kernel.
I'm told that System V.4 is rather like two big rocks, stuck together with
a small amount of glue. I don't see why that is `preferable.' I would
tend to prefer pure Berkeley with a few concessions made (like a compatible
tty driver) to ease the porting of System V stuff. In fact, I would tend
to prefer pure-something-simpler-than-berkeley, with all concessions for
compatibility at the library level or in user level servers.
Some things I will agitate for are v9 style pipes and stream i/o,
and putting system objects into the file system name space. I will
also agitate against the creeping featurists, but I don't know if
it will do much good. Even if the feeping creaturists win, I suppose
those of us who care can spend a few months removing features to
get a clean, small, system, and distribute it ourselves.
--
Mike Haertel <mi...@stolaf.edu>
``There's nothing remarkable about it. All one has to do is hit the right
keys at the right time and the instrument plays itself.'' -- J. S. Bach
Frank Mayhar
Oh boy! Now you've asked for it! :-)
}What kinds of features or design rationale should it use?
}For instance:
}
}File system: SysV vs Berkeley? Something better?
} Embedded file types? >32-bit file offsets?
Something better, but compatible, at least at some level. How about
embedding B-tree indexed file structure in the file system? (This
would let you do things like use strings to lookup records in a file,
even from the kernel. Might also let you have sorted (*gasp*)
directories.) Some sort of symbolic link idea might be nice. Use
a global directory concept for maintaining subdirectories, to speed
directory searches. And let mounted file systems span devices!
}Security: ACLs? Get rid of root? Security monitors? Auditing?
} Provably secure(A1)?
Better security is always a good thing. Security's not my forte, so
I'll leave it alone.
}Scheduler: Real-time support? Task-driven? Event driven?
} Direct brain hookups:-)?
How about scheduling processes on a per-login basis, rather than
per-process. I.e. a user has a certain quantum that is divided
between all the processes he starts. (It should be configurable,
and maybe even adjustable on the fly by a privileged user.) This
would keep one user from starting sixteen compiles and bringing a
system to its knees.
}Virtual Memory: Should GNU run on non-VM machines? Algorithm ideas?
} How general (map *everything* into VM space, like Multics)?
} Shared libraries?
I like the SunOS virtual memory concept (minus the current crop of bugs, of
course). If you're writing a Real Operating System, why worry about machines
that won't support virtual memory. Hell, by the time Gnu is ready, non-VM
machines will probably be a thing of the past anyway. Shared libraries
are good. Shared instruction space (text?) is another good idea, that can
help save on memory requirements for often-used programs.
}Networking: NFS? RFS? Something better?
} Interfaces: Streams? TLI? Something better?
} TCP/IP? OSI? SAA/SNA:-)?
} RPC Services? What kind?
Something better. But don't ask me what. NFS is OK, but it has problems.
You would want to support TCP/IP, at least at first (maybe using the BSD
code), but OSI is probably the way to go. SNA makes me gag. (Actually,
all of IBM makes me gag. :-)
}Overall Design: What nice ideas from other OSes could we use?
} Multics? VMS? VM? DG/OS?
} Fault tolerance?
See above. A lot of these ideas come from the way a particular mainframe
operating system was designed. An OS which is going the way of the Dodo,
unfortunately. Name withheld to protect the guilty.
}How about this? Make everything a user process which serves
}a resource to a client. Resources include the CPU (scheduler),
}memory (VM), disk (file system), network (sockets, etc),
}serial lines (terminal handlers), etc. Each server determines the access
}method and security criteria for its service. Make no arbitrary policy
}decisions regarding a service! Don't like the VM server? Replace it! You
}could have a security monitor provide a security policy on behalf of
}your file system or IPC mechanisms. If you have no need for security,
}don't run the monitor.
Excellent idea! Promotes modularity, and allows flexibility. Almost a
plug-and-play operating system. One problem, though: there would have
to be some sort of privilege level system, so that the resource handlers
can do things like write other user's memory, directly access devices,
re-map memory, etc. And you would have to provide at least minimal
functions in each module in the initial release. Not everybody is
an OS developer.
That's my $2.95 worth. Next?
--
Frank Mayhar ..!uunet!ladcgw!frank (fr...@ladc.bull.com)
Bull HN Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
news
>>What kinds of things should be in the GNU Kernel?
>
>Why do you ask? Will this actually have an effect on the GNU kernel?
I was talking to John Gilmore (g...@toad.com) about the GNU kernel,
and he suggested I try starting a discussion on comp.unix.wizards
about features and design of the GNU kernel. I probably should have
specifically said this.
>My opinion is that the GNU kernel should either provide an exact
>duplicate of a standard UNIX system interface, preferably SVR4,
>or it should be a quantum leap forward in OS design. The latter
>will not be achieved by piling "features" into it.
I agree that creeping featurism is not the way to go. I had intended
that those features be starting points of discussion about their
desirability and design, i.e., "I do/don't like this, and here's why,
and here's my idea for something better". Since GNU is not constrained
by compatibility with existing source code, I would hope that the
"quantum leap" would be the way to go. I certainly think that a
redesign can be done without sacrificing source code compatibility.
By the way, what do you think about my idea for kernel design?
Please flame away (and maybe say something nice, too).
--------------------------------------------
James Buster
Mad Hacker Extraordinaire
bit...@lonewolf.sun.com
--------------------------------------------
Jim Frost
I'm not sure about for the GNU kernel, but some of my wish list follows.
There should be at least three ways to start multiprocessing: fork(),
thread(), and spawn(). In addition to wait() there could be an
explicit join(), although I admit that this is damned easy to write
anyway. Note that the addition of thread probably means you'll want a
bunch of thread-control calls, but I suppose you could get by without
them.
It would be nice to have a means of reassigning the controlling
terminal of a process, eg attach().
Installable/uninstallable device drivers; kernel rebuilds work but
dammit I hate waiting.
Cleaner networking. I'd really like to have something like
'open("/dev/network/tcp/bu-cs/1024", O_RDWR)', but I'm flexible. It
might be nice to use the filesystem abstraction for everything,
although I admit that this would bottleneck (at least for open()).
I'm sort of in favor of a meta-root (not really a fs) anyway.
Block-pipes. The character-pipe is a wonderful thing but it sure
makes dealing with blocks of data a pain.
I could probably come up with others, but I'm interested in what
other people want. Not particularly interested in compatibility with
current systems if incompatibility makes things much cleaner....
jim frost
software tool & die
ma...@bu-it.bu.edu
Barry Shein
The problem with asking this question is that it first presumes what
the GNU/OS will be used for.
The note I just read (a few notes back) seemed to presume that GNU/OS
had better provide a lot of features desireable in a time-sharing
environment with lots of potentially stupid/hostile/careless users.
My guess is that it will be most attractive to the person with a
primarily single-user machine (workstation, high-end PC etc.) I would
tend to weight priorities toward that kind of user.
Something I think important is that the kernel be designed well for a
lot of parallelism.
CPU's are cheap commodities (bus bandwidth ain't tho.) I wouldn't be
surprised if personal class machines with 8 or 16 20+MIPS CPUs start
showing up in the next very few years. Most of the Unix's around today
can't accommodate that very well, mostly because the good ideas are
still waiting to be thought.
I'll also predict that 64Mb memory chips are not as far away as
readers might think which means PC's with main memories larger than
what we now consider generous *disk* configurations (eg. the 4MB
system of today becomes the 256MB system of tomorrow) should be
commonplace.
Another thing that should be coming is lots of real-time networking
with lots of data coming and going (eg. ISDN with all sorts of
wire-services and your computer sitting at home sifting through all
day for interesting things to show you when you come home.)
And multi-media environments (video, voice, hypertext, on-line
libraries, data gloves, MIDI, 3d heads-up displays, computerized
clothing with tactile feedback, cyberspace...) We're going to need a
lot of control over the time domain to make all that work, that's an
OS issue.
With hardware like that lots of things will have to be re-thought.
It's not just more of the same thing, at some point quantitative
changes force qualitative re-evaluation, new things become possible,
new needs arise, the formerly unimportant suddenly becomes critical.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
Pavan Vohra
For what good this will do --
In article <22...@thor.acc.stolaf.edu> mi...@stolaf.edu writes:
>In article <10...@smoke.BRL.MIL> gw...@brl.arpa (Doug Gwyn) writes:
>>In article <106...@sun.Eng.Sun.COM> bitbug (James Buster) writes:
>>>What kinds of things should be in the GNU Kernel?
>>My opinion is that the GNU kernel should either provide an exact
>>duplicate of a standard UNIX system interface, preferably SVR4,
>>or it should be a quantum leap forward in OS design. The latter
Good points. A third one:
Or it should be contemporary UNIX made simple and consistent.
Get rid of obsolete system calls and library functions. Make them
orthogonal. Get rid of the non-getopt options in ar and touch.
Use getopt, for Heaven's sake. And be sane about things like date
formats. Why not use timec in touch? How about a simplified ps for
other commands? Split /usr/lib off to /usr/cmdlib/bin or something.
You cannot execute an archive. Get rid of obsolete commands. Don't
make the kernel do anything that can reasonably be done in a library.
Get rid of origin-specific things (e.g. LBL, Cory, and Evans in finger).
Don't let nontechnical issues affect it. OSF and UI are doing enough
of that. Sacrifice marginal compatibility. Or just use something like
this:
llib-lold (including emulations of obsolete system calls)
/usr/old/bin
/usr/old/man (with a new manual section)
>The major goal of the GNU project has been compatibility with Berkeley
>UNIX, and then improvements. Now that POSIX is beginning to solidify,
Oh, well.
>those of us who care can spend a few months removing features to
>get a clean, small, system, and distribute it ourselves.
O.K. But why have them there in the first place? Maybe you can get to
GNUmarket faster if you have a better GNU in the first GNUplace. Maybe
it will be a better GNUmarket.
>--
>Mike Haertel <mi...@stolaf.edu>
>``There's nothing remarkable about it. All one has to do is hit the right
> keys at the right time and the instrument plays itself.'' -- J. S. Bach
Kimball, borrowing Pavan's account.
--
---
Pavan Vohra {..hplabs|ames|ihnp4|decwrl}!amdahl!vohra
Amdahl Corporation
Sunnyvale, CA 94086-3470
---
Mike Marshall
> It would be nice to have a means of reassigning the controlling
> terminal of a process, eg attach().
>
There's already an ioctl that'll do this. I like to refer to it as the
"make me root" ioctl call.
-Mike Marshall hub...@hubcap.clemson.edu
Don Faulkner
...
Pavan> llib-lold (including emulations of obsolete system calls)
Pavan> /usr/old/bin
Pavan> /usr/old/man (with a new manual section)
...
My guess: GNU will use .../emacs/info/ and have all documentation in
texinfo/info format (Geeeee hypertextish manuals, online indexes ....)
--
Don Faulkner
Building 1, Room 803
Harvard University, School of Public Health
665 Huntington Avenue
Boston, MA 02115
ARPA: faulkner%jmul...@harvard.harvard.edu
BITNET: faulkner@harvard
Telephone: (617) 732-2297
Don Alvarez
A few observations on security...
(1) Every OS implementation has (or will have) bugs, and some of them
are going to be security related bugs (note I said _implementation_,
as distinct from _theory_).
(2) The Internet Virus was able to propagate effectively because
almost everybody used one of two different systems with a number
of standard bugs.
(3) It generally takes human hackers a few tries to break into your
system, and (imho) the best defense against them is good logging
of strange behavior. (you have to assume that someone will
eventually crack your security, but they will probably have left
traces of themselves by the time they do).
(4) If you have good backups and a logfile entry showing when your
security was breached, the amount of damage an intruder can do to
your files is severely limited (release of classified/confidential
data not withstanding).
...and a few conclusions based on those observations...
(1+2) GNU's main security advantage will probably be that there is no
'standard' security system. People will (hopefully) hack and
code to their heart's content, logging or checking whatever
random things they think are significant on their system. The
more hacked the systems become, the less likely it is that
everyone's fingerd will have the same bug, and without those
'standard' bugs, network viruses will have a much harder time
propagating.
(3+4) Assuming you have some threshold amount of security, improving
your logging capabilities is probably more effective than
improving your defenses. No matter how good your security, if
a wizard really wants to get in, he will. If you keep (and
read!) good logs, and if you back up every day (don't just
talk about it!), then the evil wizard can't trash more than
one day's work.
Q: What single thing would I recommend?
A REALLY REALL REALLY easy way to tell my system to prompt me for a
tape every morning, dump all changes since the previous morning,
_and_eject_the_tape (don't leave your backups where the system can get
at them). Once a week/month/ten days/etc the system would prompt me
for several tapes and automatically do a full backup. This has the
advantage that it protects you from well-meaning good guys ("rm *.c?
aaarghh!") as much as it protects you from ill-meaning bad guys. If
your password is like your toothbrush (use it everyday, change it
regularly, and don't share it with friends), then doing backups is like
flossing (everybody talks about it, nobody does it).
Closing musings:
On the subject of security, you were probably more interested in
questions like "what encryption algorithm should we use" (or even the
more radical "should we continue to have world-readable password
files"), "should we allow rsh-style remote procedure calls", "should
we include kerberos hooks", etc. I'd say go ahead and leave
/etc/passwd the way it is, but try to come up with a simple password-
checker to make sure people don't use password=account-name couplets.
rsh is tougher, because it's so common as to be almost mandatory. And
yes, I think kerberos is a darn good way to handle inter-host
communications.
-Don Alvarez
--
+ -------------------------------------------------------------------------- +
| Don Alvarez M.I.T. Center For Space Research (617) 253-7457 |
| boo...@SPACE.MIT.EDU Moving Soon: Princeton University Gravity Lab 8/89 |
+ -------------------------------------------------------------------------- +
Leslie Mikesell
>What kinds of features or design rationale should it use?
>For instance:
>File system: SysV vs Berkeley? Something better?
> Embedded file types? >32-bit file offsets?
Virtual file systems of course, with support for SysV/BSD/Xenix and
MSDOS (extendable to anything that can provide reasonable answers
to opendir/readdir, etc.)
>Security: ACLs? Get rid of root? Security monitors? Auditing?
> Provably secure(A1)?
Basic unix rwx built-in, plus per-filesystem switch controlling support
for setuid bits on that fs (allowing user-level mounts of removable media).
>Scheduler: Real-time support? Task-driven? Event driven?
> Direct brain hookups:-)?
Add a per-user CPU quota such that multiple processes started by the
same user could only take a specified total of system resources.
>Virtual Memory: Should GNU run on non-VM machines? Algorithm ideas?
> How general (map *everything* into VM space, like Multics)?
> Shared libraries?
Why bother with anything that can't do VM? Put everything but the scheduler
and swapper into VM space, allow shared text, copy-on-write forks, shared
libraries and sharable data space. Allow processes to lock certain areas
of themselves into real non-swapped memory if they need to approximate
real-time response. Provide tools to generate a load image that will
optimize VM usage by profiling a sample run and generating a new load
map that would minimize the VM activity.
>Networking: NFS? RFS? Something better?
> Interfaces: Streams? TLI? Something better?
> TCP/IP? OSI? SAA/SNA:-)?
> RPC Services? What kind?
All of the above, as user-loadable add-ons. Hide NFS/RFS behind a
virtual file system. The kernel should only know about the network
device with other support in user space.
>Overall Design: What nice ideas from other OSes could we use?
> Multics? VMS? VM? DG/OS?
> Fault tolerance?
How about the ability to do a reasonable backup with the ability to
restore the machine to various states (restore system to installed
state -including programs that happen to be running-, restore non-system
files only, restore modified system files only, etc.). There should
be a mechanism to optimize disk locations during a restore. Since
there will be no limitations on the distribution of a copy of GNU it
should be made convienient to make a system image and duplicate it
without having to go through all the steps for each machine.
Les Mikesell
Rich Neitzel
One thing that I would dearly love is good asynch. support. A set of
routines that would allow one to do issue an I/O request and specifiy
a flag/semaphore that can latter be checked or waited on.
-------------------------------------------------------------------------------
Doug Gwyn
>By the way, what do you think about my idea for kernel design?
Which idea was that? If it was to keep the actual kernel as minimal
as possible, I don't think anyone could have conceptual disagreement
with that. However, one has to be careful not to force gross
inefficiency by doing too little in the kernel. An example of this
is the user-mode XT protocol and multiplexing via ptys typically
done on BSD-based systems to support 5620/630-class ("Blit-like")
terminals; the context switch overhead is horrendous.
Scott Schwartz
and I have been advocating recently. We have a 4.3 implementation
about half done now, so by the time GNU gets rolling there will be
some prior art to build upon.
[For those who missed it, unix++ virtualizes the file access system by
extending open() to include modes O_NONE, O_EXEC, and O_CHANGE, and by
adding system calls fchdir, fexec, etc.]
--
Scott Schwartz <schw...@shire.cs.psu.edu>
Peter da Silva
> What kinds of things should be in the GNU Kernel?
1) Start with Mach.
2) Start with Mach...
> What kinds of features or design rationale should it use?
Start with Mach...
> For instance:
>
> File system: SysV vs Berkeley? Something better?
The Berkeley directory structure is, ahem, baroque. 14 character file
names are too short. 255 is ridiculous. Just increase the size of
struct dir to 32 bytes and use 30 characters. Working with AmigaDOS
I've found case-preserving files with case-ignoring searches is very
handy.
> Embedded file types?
NO.
> >32-bit file offsets?
It will have to do this.
More bits in st_flags, so you don't have to do weird overlays of ISVTX
and ISGID (or whatever it is) to implement symlinks... or the next neat
hack.
Watchdogs (see recent Usenix paper).
> Security: ACLs?
Perhaps. This would solve the bits-in-st_flags problem.
> Get rid of root?
Hmmm. Go to something like DEV:path as per VMS/AmigaDOS/MSDOS/...?
Handy, particularly if you have assigns. But too many incompatibilities.
> Security monitors? Auditing?
> Provably secure(A1)?
Not possible, I think, with the resources GNU has.
> Scheduler: Real-time support? Task-driven? Event driven?
> Direct brain hookups:-)?
Threads. See 1) 2) and 3) above...
> Virtual Memory: Should GNU run on non-VM machines? Algorithm ideas?
> How general (map *everything* into VM space, like Multics)?
> Shared libraries?
See above.
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Jim Shankland
>>What kinds of things should be in the GNU Kernel?
>
>duplicate of a standard UNIX system interface, preferably SVR4,
I vote for the quantum leap forward. With a little luck and a lot of
skill, arbitrary 4.2, v7, SVR4, etc. UNIX features can be layered on
top as library packages, which makes feeping creaturism less of an evil.
My wish list: a tiny, but extensible kernel. A hierarchcal object name
space taking the place of the file system. Several kinds of objects for
starters: byte-array like things, including address spaces, disk files,
frame buffers, etc.; data-stream like things, including IPC channels,
terminal devices, etc.; protocol-like things, including both one-input,
one-output things like line disciplines (or anything that's like AT&T
streams), and one-input, many-output (and vice versa) things like TCP,
UDP, etc.; and array multiplexor things like file systems (which take
a large array -- a disk partition -- and split it up into multiple smaller
arrays -- files); and threads.
The code implementing these objects should be freely configurable into the
kernel or into user processes. Thus, the kernel could end up being tiny,
or gargantuan, depending on how the system is configured.
Much hand waving here, I know. But I believe there's gold in them thar
hills. You go find it, though. Me, I have to pick up my shirts at the
cleaners ....
Jim Shankland
j...@ernie.berkeley.edu
"Blame it on the lies that killed us, blame it on the truth that ran us down"
a.v.reed
>>What kinds of things should be in the GNU Kernel?
>duplicate of a standard UNIX system interface, preferably SVR4,
>or it should be a quantum leap forward in OS design. The latter
>will not be achieved by piling "features" into it.
The problem with most evolved OSs is that implementation bugs
get fixed, but fundamental design bugs tend to stay around. How
many times have you wished that directories were flat text files,
so you could use "grep" and other text tools on them? How many
times have you wished for a flat text "/inodes" file for each
file system? How many times have you wished that /proc contained
directories with a separate file for each segment? or to be able
to attach a shared memory segment just by opening an in-memory
file?
I would applaud GNU if, instead of copying an existing
design, or trying for a quantum leap, or piling on features, they
just designed their kernel and file system to correct the most
annoying wrong turns of the existing designs. Am I dreaming?
Dave Decot
> > terminal of a process, eg attach().
>
> There's already an ioctl that'll do this. I like to refer to it as the
> "make me root" ioctl call.
No, this ioctl() reassigns the associatd process group of a terminal
device. It does not change the controlling terminal of any process.
Dave
Dave Decot
> > terminal of a process, eg attach().
>
> There's already an ioctl that'll do this. I like to refer to it as the
> "make me root" ioctl call.
If you're thinking of TIOCSPGRP, this ioctl() reassigns the associated
process group of a terminal device. It does not change the controlling
terminal of any process. And anyway, most Real Systems(tm) have closed
this ridiculous security hole.
Dave
Steve Savitzky
>In article <106...@sun.Eng.Sun.COM>, ne...@sun.Eng.Sun.COM (news) writes:
>> What kinds of things should be in the GNU Kernel?
>>
>> File system: SysV vs Berkeley? Something better?
>
>The Berkeley directory structure is, ahem, baroque. 14 character file
>names are too short. 255 is ridiculous. Just increase the size of
Personally, I like 255-character filenames (well, maybe 127), for
filenames like "comp.unix.wizards-more.stuff.about.GNU.OS". I HATE
arbitrary limits, especially when they're small. The Macintosh :-( has a
32-character limit and I run up against it all the time. This is
especially true when you have a browser (like dired) that lets you
point to a file and open it instead of having to type the whole name.
For networking I rather like the way Apollo handles a networked name
space (it's about the ONLY thing to like about Apollo :-) -- Root is /
and the network layer above it is //, so a complete pathname looks
like (e.g.) //steve/usr/bin
IMHO this is better than the way NFS does it (i.e. mounting
filesystems in random places) -- everything is in exactly one place in
the hierarchy.
Also, device drivers and even file systems (meaning directory
managers, not U*IX filesystems) ought to be ordinary processes that
work by exchanging messages. This makes them loadable and unloadable
at any time. In a network, you probably have to have some way of
specifying whether a particular executable can run on any machine, or
only on a specific one (e.g. the one your MIDI keyboard is attached to).
--
Stephen Savitzky apple.com!arc!steve
ADVANsoft Research Corp. (408)727-3357
4301 Great America Parkway #include<disclaimer.h>
Santa Clara, CA 95054 May the Source be with you!"
Rahul Dhesi
filenames containing // and it takes special case code [note 1] to
handle such filenames. And some systems want // to mean something
special.
On the other hand, if you call root "root", then "cd root" can be
ambiguous (as was pointed out to me today).
How about reserving a leading ^ to mean root and temporarily accepting
a leading / as a synonym for compatibility?
^/usr/bin == /usr/bin
cd ^ == cd /
For networking, ^^ could be special, sort of like // but without the
overloading of //.
Note 1. UNIX handles // by assuming that there is a null filename
component between the two slashes. Unfortunately this allows legal
filenames like /bin//cat and even /bin//////cat which, if a program is
trying to parse pathanmes, is painful.
--
Rahul Dhesi <dh...@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Career change search is on -- ask me for my resume
Stephen J. Friedl
>
Who would ever believe that RMS would come up with an A1 system?
Steve :-)
--
Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442
3B2-kind-of-guy / fri...@vsi.com / {attmail, uunet, etc}!vsi!friedl
"Embrace your dealer: hugs *and* drugs" - me
James Buster
This was my original idea. It clearly needs refinement.
I also probably used the term "user process" incorrectly
in this description. Oh well.
# How about this? Make everything a user process which serves
# a resource to a client. Resources include the CPU (scheduler),
# memory (VM), disk (file system), network (sockets, etc),
# serial lines (terminal handlers), etc. Each server determines the access
# method and security criteria for its service. Make no arbitrary policy
# decisions regarding a service! Don't like the VM server? Replace it! You
# could have a security monitor provide a security policy on behalf of
# your file system or IPC mechanisms. If you have no need for security,
# don't run the monitor.
--------------------------------------------
James Buster
Mad Hacker Extraordinaire
bit...@lonewolf.sun.com
--------------------------------------------
--
John R. Bashinski
>What kinds of features or design rationale should it use?
Well, I've never done any OS design, but nobody can claim I'm not
opinionated :-)...
The most important thing is to build a framework in which things can be
added later. It's not important to provide a lot of user functionality
that's not in existing systems. What is important is not to make any
decisions that'll prevent somebody else from adding it later. That'll
be difficult enough. The module interface designs will probably be the
most enduring part of the whole system.
Make the system lean and, and make it configurable, so people can choose only
the code they need. Allow as much dynamic reconfiguration as possible. If
it's not too hairy, support SysV.4 device drivers and streams modules. Put
emulation for BSD calls (or SysV calls, or whatever) in libraries, not in
the kernel, unless it *really* needs to be there.
It's important to support multiprocessors and allow for tightly-coupled
distributed systems. No non-reentrant code. Good locking and synchronization
primitives, available both within the kernel and outside it, probably
message-based. Do this stuff right, allow user processes to run in kernel
VM space, and keep your interrupt handling clean, and you can go a long
way toward letting somebody add a real-time scheduler to the system later.
Multiple threads of control: Decouple threads of control from address
spaces. It should be possible to have more than one thread in a given
address space, and to have the scheduler manage that for you. It might
be nice to be able to start a thread of control in *somebody else's*
address space (maybe even in kernel address space), to manipulate other
address spaces and other threads in other ways.
Extensions to the filesystem name space: Everything (from the user's point
of view) should be a file. That means real files, devices, pseudo-devices,
network connections to other machines, VM address spaces other than your
own, data about threads, scheduler control, everything. When you open a
file, you establish a connection to some kind of object. It may be
implemented by kernel code or by user-mode code. You can send data to it,
read data from it, maybe seek it, and maybe map it into your address space.
What it does with your data is type-specific. You can also send it
type-specific commands, using something like ioctls, but more general;
perhaps typed reads and writes. It can generate events that wake you up
and/or signal (or something better than signal!) you when it has data for
you. It should be possible for user-mode code to "get behind" mount points,
and maybe even disk "files" and "directories", and provide services. It
should be possible to have the trailing part of a pathname passed to
whatever implements a "directory" for further processing. This probably
means that there need to be directory access mechanisms built into the file
system primitives, so these objects can tell programs what's available in
the name space. There probably also needs to be some kind of unique object
identifier that can be a successor to the inode.
>File system: SysV vs Berkeley? Something better?
> Embedded file types? >32-bit file offsets?
The Berkeley file system (perhaps slightly augmented) would be fine for
disks, at least for now. Heathen file systems without symbolic links would
not be adequate :-). It's more important to build a flexible operating
system foundation than to design a new disk structure. The file system
definitely shouldn't worry about the type of the data in a file until
much, much later on.
>Security: ACLs? Get rid of root? Security monitors? Auditing?
> Provably secure(A1)?
There's no need for ACL's, or A1 security, or auditing, or whatever just yet.
There *do* need to be hooks for providing these things. That basically means
that a reference monitor interface needs to be designed, and that the system
needs to channel requests for access through it. There needs to be a clear
definition of what objects have privileges, what operations may require
privileges, how privileges get passed around, how to *prevent* privileges
from getting passed around, and so forth.
Glimmerings of a structure: Privileges belong to threads of control; each
thread has a privilege list. A privilege is represented by a unique
identifer, which subsumes the functions of both UNIX UIDs and GIDs.
Certain of a thread's privileges are marked as corresponding to real
and effective UNIX UIDs and GIDs. Privileges in a thread's privilege
list have other binary attributes, things like "can/can't be delegated",
"can/can't be given up", "pass/don't pass on fork", and so forth. Some
attributes can be modified by the thread, others can't. A reference
monitor gets called by whatever implements a file/object to examine
opens, closes, reads, writes, and control operations. The reference monitor
is allowed to issue a capability identifier of some kind at object open,
and can restrict how that capability can be delegated. Whenever an operation
is attempted on the opened object, the object implementation passes the same
capability to the reference monitor as part of the information about the
operation. It may choose to revoke a capability at any time.
Issues: When you open a "file", does the object at the other end get your
privileges by default? Can you change the default? What code is allowed
to issue privileges?
>Scheduler: Real-time support? Task-driven? Event driven?
> Direct brain hookups:-)?
Start with the simplest scheduler you can get away with... and make it
easy to replace. Real-time people seem to like to write their own schedulers
anyway.
>Virtual Memory: Should GNU run on non-VM machines? Algorithm ideas?
> How general (map *everything* into VM space, like Multics)?
> Shared libraries?
It would be nice to have a well-defined subset of the system that could
be run on a non-VM machine, but the full-blown system needs to offer
functions that you can only get with virtual memory.
*Everything* should be in the file system name space... and it should be
possible to map anything sensible from the file system into your VM space.
That doesn't mean that everything needs to be mapped by default, though.
There needs to be support for wiring down pages, user-defined paging
strategies, read-only mapping under user control, and maybe copy-on-write
(there definitely shouldn't be any choices made that would preclude
copy-on-write).
Shared libraries (which are a good idea) can be supported in user code.
No need to clutter the kernel with anything more complicated than file
mapping.
>Networking: NFS? RFS? Something better?
> Interfaces: Streams? TLI? Something better?
> TCP/IP? OSI? SAA/SNA:-)?
> RPC Services? What kind?
My personal desires: Definitely TCP/IP. Definitely NFS. Maybe RFS. Maybe OSI.
Make it easy to add stuff. Use Streams/TLI (perhaps somewhat extended) for
the real networking code, but provide a socket emulation library.
>Overall Design: What nice ideas from other OSes could we use?
> Multics? VMS? VM? DG/OS?
> Fault tolerance?
>
>How about this? Make everything a user process which serves
>a resource to a client. Resources include the CPU (scheduler),
>memory (VM), disk (file system), network (sockets, etc),
>serial lines (terminal handlers), etc. Each server determines the access
>method and security criteria for its service. Make no arbitrary policy
>decisions regarding a service! Don't like the VM server? Replace it! You
>could have a security monitor provide a security policy on behalf of
>your file system or IPC mechanisms. If you have no need for security,
>don't run the monitor.
I'm not sure how you'd put the scheduler in a user process, but this
is basically a good way to go... provided that you can get decent performance
out of it. Some of these processes could probably run in the kernel's address
space. I think that putting things in the file system name space is a good
way to provide access to the resource managers for everything but the
two really essential resources, CPU and memory, and even for some of the
fine control over those.
--
John R. Bashinski jo...@sj.ate.slb.com {amdahl,decwrl,uunet}!sjsca4!johnb
+1 408 437 5218 M/S 32-0846, 1601 Technology Drive, San Jose, CA 95110
Peter da Silva
> In article <43...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
> >The Berkeley directory structure is, ahem, baroque. 14 character file
> >names are too short. 255 is ridiculous. Just increase the size of
> >struct dir to 32 bytes and use 30 characters. ..
> Personally, I like 255-character filenames (well, maybe 127), for
> filenames like "comp.unix.wizards-more.stuff.about.GNU.OS".
That's a problem hierarchical directories are better at solving. I'd call
that "news-junk/comp.unix.wizards/more_stuff_about_GNU-OS".
> I HATE
> arbitrary limits, especially when they're small. The Macintosh :-( has a
> 32-character limit and I run up against it all the time.
Sounds like you have a problem with the Mac. Don't you know that you're
supposed to do everything with those cute little icons?
> This is
> especially true when you have a browser (like dired) that lets you
> point to a file and open it instead of having to type the whole name.
I have a program like that on the Amiga (called Browser). I still prefer
shorter file names because they allow me to fit more columns of files in
a convenient-sized window.
> For networking I rather like the way Apollo handles a networked name
> space (it's about the ONLY thing to like about Apollo :-) -- Root is /
> and the network layer above it is //, so a complete pathname looks
> like (e.g.) //steve/usr/bin
OpenNET does this, too. It's very convenient. No surprises.
> Also, device drivers and even file systems (meaning directory
> managers, not U*IX filesystems) ought to be ordinary processes that
> work by exchanging messages.
Sounds like the Amiga. Or, more conventionally (for the UNIX world) like
Mach.
Glenn Fowler[drew]
> I suggest finding a better syntax for root than "/". It can lead to
> filenames containing // and it takes special case code [note 1] to
> handle such filenames. And some systems want // to mean something
> special.
I suggest finding a better name for network root than "//". We already
have a consistent name space, why complicate it with new syntax. A
compatible name for network files could be "/n/machine/goop"
(not my invention, used in V9). Better yet, this allows machine hops
without the ambiguities introduced by special leading character syntax:
"/n/bambi/n/thumper/goop" vs. "//bambi//thumper/goop".
--
Glenn Fowler (201)-582-2195 AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,decvax,ucbvax}!ulysses!gsf internet: g...@ulysses.att.com
Mike Marshall
* * * There's already an ioctl that'll do this. I like to refer to it as the
* * * "make me root" ioctl call.
* * *
* * No, this ioctl() reassigns the associatd process group of a terminal
* * device. It does not change the controlling terminal of any process.
* *
*
* If you're thinking of TIOCSPGRP, this ioctl() reassigns the associated
* process group of a terminal device. It does not change the controlling
* terminal of any process. And anyway, most Real Systems(tm) have closed
* this ridiculous security hole.
*
You have to read between the lines of the tty(4) man page, but there is
an easy way to "essentially" change the controlling terminal of a
process (at least, you can still do it with ULTRIX 3.0) and it is
quite a security hole.
-Mike Marshall
Bruce G. Barnett
>Personally, I like 255-character filenames (well, maybe 127), for
Long filenames are great. I use filenames all the time to hold
extra information, which allows database queries using shell meta-characters.
>IMHO this is better than the way NFS does it (i.e. mounting
>filesystems in random places) -- everything is in exactly one place in
>the hierarchy.
If you want to criticize your system managers, this is not the place to do it.
--
Bruce G. Barnett <bar...@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]>
uunet!crdgw1.ge.com!barnett bar...@crdgw1.UUCP
Tom Frauenhofer
>In article <106...@sun.Eng.Sun.COM> bitbug (James Buster) writes:
>}What kinds of things should be in the GNU Kernel?
"Oh boy!" is right! :-)
>}What kinds of features or design rationale should it use?
>}For instance:
>}Scheduler: Real-time support? Task-driven? Event driven?
>} Direct brain hookups:-)?
>How about scheduling processes on a per-login basis, rather than
>per-process. I.e. a user has a certain quantum that is divided
>between all the processes he starts. (It should be configurable,
>and maybe even adjustable on the fly by a privileged user.) This
>would keep one user from starting sixteen compiles and bringing a
>system to its knees.
Fair to users, maybe. How would you handle daemons? Is each daemon its
own process group? Or can they be grouped together somehow?
Even if you do this, the processes will still get in the way of each other
due to paging requirements. You would have to go to a local paging/working
set system to cut out this interaction. This is a gain if one of your goals
is real-time, but it requires a more intelligent user who can determine an
optimum working set size.
Another way processes interfere with each other is the kernel call mechanism
that UNIX uses where (I recall, mucho simplified) when one process is making
a kernel call others cannot (unless, of course, the process in the kernel is
blocked for some reason, say on a semaphore or because it is waiting on an
I/O call to be serviced).
All of the above have been done in various OS's. It all boils down to the
goals of the GNU team (which is point I don't know much about). Do they
want to emulate UNIX? Or do they want to come up with something different?
It would be nice to see their design goals spelled out.
Mind you, none of this will affect the GNU kernel design one whit...
Thomas V. Frauenhofer ...!rutgers!rochester!cci632!ccird7!tvf
*or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477
FRAU BBS: (716) 227-8094 2400/1200/300 baud - log in as "new" to register
Doug Gwyn
>I suggest finding a better syntax for root than "/".
[Obviously we're no longer talking about backward compatibility with UNIX.]
I don't think there should be a namesystem root. I recently sent DMR some
notes about a new concept that would permit us to get rid of namesystem root,
among other things. I don't know whether anything will come of it..
Maarten Litmaath
\... and if you back up every day (don't just
\ talk about it!), then the evil wizard can't trash more than
Have you ever heard of `poison pots'?
--
"Your password [should be] like your |Maarten Litmaath @ VU Amsterdam:
toothbrush." (Don Alvarez) |ma...@cs.vu.nl, mcvax!botter!maart
Leslie Mikesell
[RE: GNU]
>[For those who missed it, unix++ virtualizes the file access system by
>extending open() to include modes O_NONE, O_EXEC, and O_CHANGE, and by
>adding system calls fchdir, fexec, etc.]
How about an open mode of O_NOSYNC that would mean that the file is
temporary and there is no need to flush the buffers to disk except
when the space must be re-used. This should automatically be set
for pipes and for blocks whose file has been deleted before closing.
Perhaps the mode should be inherited from the directory also. How
much system time is wasted flushing buffers to /tmp that nothing
ever intends to re-use?
Les Mikesell
Greg Woods
> filenames containing // and it takes special case code [note 1] to
> handle such filenames. And some systems want // to mean something
> special.
> Note 1. UNIX handles // by assuming that there is a null filename
> component between the two slashes. Unfortunately this allows legal
> filenames like /bin//cat and even /bin//////cat which, if a program is
> trying to parse pathanmes, is painful.
First, null directory components in pathnames are extremely easy
to parse, and are a desirable feature. Second, a leading '//'
with a special meaning is a tremendous KLUDGE! It's even worse
than "machine_A:/"!
I HOPE to see future distributed filesystems become (remain :-)
completely transparent ala RFS. You should be able to mount any
(advertised) directory from any machine on the network anywhere
into your local filesystem hierarchy.
--
Greg A. Woods
woods@{{utgpu,eci386,ontmoh,tmsoft}.UUCP,gpu.utcs.UToronto.CA,utorgpu.BITNET}
+1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario CANADA
Peter da Silva
> a leading / as a synonym for compatibility?
If you're going to change the name of root, how about '%'? '^' is already
in use on both /bin/sh and cshell.
Personally, I like named devices. Have the root be "%root" (Chosing a prefix
for file naming consistency). Then remote systems and devices become parallel
and you can play games with assigned names and symlinks to get the current
tree structure...
mount /dev/rdsk/c0d0s0 /usr -> ln -s %root/usr %c0d0s0
If the prefix bugs you, you can always go VMS:
ln -s root:/usr c0d0s0:
(do you make it %/usr or %usr? Do you make it root:/usr or root:usr????)
Peter da Silva
> When you open a
> file, you establish a connection to some kind of object. It may be
> implemented by kernel code or by user-mode code. You can send data to it,
> read data from it, maybe seek it, and maybe map it into your address space.
> What it does with your data is type-specific.
So, you want a file to be an object that responds to messages like 'read',
'write', 'attach', etc...
> type-specific commands, using something like ioctls, but more general;
> perhaps typed reads and writes.
More messages...
> It can generate events that wake you up
> and/or signal (or something better than signal!) you when it has data for
> you.
Best to fork a thread that does a wait on the fd/message-port. Make wait
accept a list or mask of events to wait on. Each thread itself has a port,
when it exits a 'died' message goes back. Parent can wait on that port and
get that message... or you can send a fake death message early...
> It should be possible for user-mode code to "get behind" mount points,
> and maybe even disk "files" and "directories", and provide services. It
> should be possible to have the trailing part of a pathname passed to
> whatever implements a "directory" for further processing.
Just have a process attached to the file system at that point, and have it
understand file messages on its port. namei() can send it such a message...
> There probably also needs to be some kind of unique object
> identifier that can be a successor to the inode.
Just another message port.
> My personal desires: Definitely TCP/IP. Definitely NFS. Maybe RFS. Maybe OSI.
> Make it easy to add stuff. Use Streams/TLI (perhaps somewhat extended) for
> the real networking code, but provide a socket emulation library.
Streams are pretty wimpy compared to a general message structure like this.
Leslie Mikesell
>There should be at least three ways to start multiprocessing: fork(),
>thread(), and spawn().
Can someone explain how a thread differs from a fork, and whether the
difference is desirable compared to forks with shared text, copy-on-write
data, and the ability to explicitly request shared memory for data?
Les Mikesell
Andrew Hume
> Long filenames are great. I use filenames all the time to hold
> extra information, which allows database queries using shell meta-characters.
storing information is what a filesystem is for.
if you want to use regular expressions, put the information
in a file. don't complicate a universal mechanism like
the file-system name space just so you can be lazy about
selecting filenames.
Pekka Akselin [The Mad Midnight Hacker]
]In article <43...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
]>
]>names are too short. 255 is ridiculous. Just increase the size of
]>struct dir to 32 bytes and use 30 characters. ..
]
]Personally, I like 255-character filenames (well, maybe 127), for
]filenames like "comp.unix.wizards-more.stuff.about.GNU.OS". I HATE
]arbitrary limits, especially when they're small. The Macintosh :-( has a
I too *HATE* arbitrary limits, it's so restrictive!
Why don't make the filename length dynamic!?
--
Pekka (Paix is my private home. VMUNIX computer and I are M.Sc. students)
-------------------------------------------------------------------------------
pe...@paix.ikp.liu.se Pekka Akselin, Sweden +46 13 172919
George Robbins
principle with the details. Of course I would prefer BSD 4.x compatibility
with a GnuFS and X and all the new wave goodies, and consider the BRL System V
compatibility package to be an adequate gesture in that direction, but I think
it's more important to get the basic system up and runnng, than to worry about
frills or new departures.
--
George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!g...@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
David C. Rein
> >What kinds of features or design rationale should it use?
> Glimmerings of a structure: Privileges belong to threads of control; each
> thread has a privilege list. A privilege is represented by a unique
> identifer, which subsumes the functions of both UNIX UIDs and GIDs.
> attributes can be modified by the thread, others can't. A reference
> monitor gets called by whatever implements a file/object to examine
> opens, closes, reads, writes, and control operations. The reference monitor
> is allowed to issue a capability identifier of some kind at object open,
> and can restrict how that capability can be delegated. Whenever an operation
> is attempted on the opened object, the object implementation passes the same
> capability to the reference monitor as part of the information about the
> operation. It may choose to revoke a capability at any time.
>
> Issues: When you open a "file", does the object at the other end get your
> privileges by default? Can you change the default? What code is allowed
> to issue privileges?
A possible solution to this problem could be similar to that of Intel's
idea of 'conforming and non-conforming' segments. When the 'object at
the other end initializes itself, it can also declare weather its a
conforming or non-conforming object. So, when you open a "file", depending
on the initialization of the object at the other end would decide the
privileges. Perhaps the reference monitor can even let some users' process
force non-conforming (so run at the high privileges) determined by the
users' profile. Since an object could be analagous to a device driver, it
is a 'situation dependent' decision , and should be handled by the kernel
in a general fashion.
(I just started reading this newsgroup, so if this idea is old, or has been
thrown around before, then sorry for the clutter...)
---
Dave Rein
UUCP: ..!kodak!gizzmo!lazlo!mobile!dave
dcr0801@ritcv
Frank Mayhar
>In article <4...@ladcgw.ladc.bull.com> I write:
>>In article <106...@sun.Eng.Sun.COM> bitbug (James Buster) writes:
>>}What kinds of things should be in the GNU Kernel?
>>per-process. I.e. a user has a certain quantum that is divided
>>between all the processes he starts. (It should be configurable,
>>and maybe even adjustable on the fly by a privileged user.) This
>>would keep one user from starting sixteen compiles and bringing a
>>system to its knees.
>Fair to users, maybe. How would you handle daemons? Is each daemon its
>own process group? Or can they be grouped together somehow?
Well, they're all started at boot time (for the most part); group them
together by forcing them to inherit the scheduling parameters of their
parent (which is init, in this case: _the_ most privileged user). Or
make the parent adjust the scheduling parameters on the fly for each
daemon, to each according to its needs. Fortunately, most daemons don't
require a lot of time; most of the time they are sleeping waiting for
something to happen. Of course, when they do need time, they need it bad,
and they may need a lot of it. So make them privileged, so that they
can change their own parameters. Or make each one a separate user,
with it's own (configured) quantum value. Then each of the children
of such processes would share the parent's quanta. One advantage:
sendmail wouldn't bring the system to its knees when it's very active.
My most important point is that this stuff should be configurable, both
by the system manager in some static location, and dynamically, at run
time, for each user, and, perhaps, for each process.
>Even if you do this, the processes will still get in the way of each other
>due to paging requirements. You would have to go to a local paging/working
>set system to cut out this interaction. This is a gain if one of your goals
>is real-time, but it requires a more intelligent user who can determine an
>optimum working set size.
Since memory is (and will probably always be) a limited resource, I don't
see any way to completely cure this. But you could prefer paging out the
pages of another process for the same user, over paging out the pages of
a process not associated with the current user. If the current user (who
needs the page[s]) only has one process, then go looking for pages from
other processes.
>Another way processes interfere with each other is the kernel call mechanism
>that UNIX uses where (I recall, mucho simplified) when one process is making
>a kernel call others cannot (unless, of course, the process in the kernel is
>blocked for some reason, say on a semaphore or because it is waiting on an
>I/O call to be serviced).
Sounds broken to me; fix it. The way we get around this is by having per-user
auto stack, control blocks, etc. When the user's quantum ends, he is put
to sleep, and we switch contexts. Obviously, there are some things that
can't be interrupted, so we have a mechanism to extend the quantum. (Or
we just automatically extend the quantum; I'm not sure, since the scheduler
is not part of the code I'm responsible for. I have the file management
system.) Basically, at the end of the quantum, we block the user. Since
our monitor is fully reentrant (with a very few exceptions), another user
can issue a monitor call with no problems.
>All of the above have been done in various OS's. It all boils down to the
>goals of the GNU team (which is point I don't know much about). Do they
>want to emulate UNIX? Or do they want to come up with something different?
>It would be nice to see their design goals spelled out.
Quite true. It would be nice to see something that used some of the good
parts of Unix, and at the same time fixed most of the broken parts. (I
know, I better go put on my flame-proof suit, now. :-)
>Mind you, none of this will affect the GNU kernel design one whit...
Also true. But I keep hoping...
--
Frank Mayhar ..!uunet!ladcgw!frank (fr...@ladc.bull.com)
Bull HN Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
Doug Gwyn
>Can someone explain how a thread differs from a fork, and whether the
>difference is desirable compared to forks with shared text, copy-on-write
>data, and the ability to explicitly request shared memory for data?
As you seem to suspect, a "thread" has its own stack and state but
shares code and data with other threads, whereas a "fork" has its
own stack, state, and data but shares just the code with the other
branch of the fork.
The supposed advantage of a thread is that it's cheap to create one,
even compared with setting up copy-on-write for a fast fork(). The
obvious disadvantage is that the shared data space requires use of
concurrency controls among the parallel threads (e.g. monitors).
Unfortunately, really good concurrency controls don't seem to exist
at present. Until someone devises a slick way to do this right in
high-level languages, I'll continue to prefer separate processes and
explicit data sharing.
By the way, Burroughs came close with their B5x00 and B6x00 series
Extended Algol implementations.
Barry Shein
n creating a process context by sharing>Can someone explain how a thread differs from a fork, and whether the
>difference is desirable compared to forks with shared text, copy-on-write
>data, and the ability to explicitly request shared memory for data?
>
>Les Mikesell
Unfortunately a "thread" is not yet a well-defined word. All it seems
to mean at this point is a light-weight process context tho some
implementations exist for guidance of a discussion.
By and large a process has several data structures associated uniquely
with its state; memory, open files, signals, ownership, resource
limits, stack state etc. A thread or light-weight process attempts to
speed up and lighten creation and other overhead by sharing some or
all of these resources with the creating process (the parent or task
in Mach.) Instead of copying resources (or creating them anew in some
cases) they are just referenced, the thread points back at the
parent's data structures. This can be done fairly quickly as compared
to copying and references are lighter to lug around than entire
structures.
Copy on write is just a lazy evaluation technique (albeit very clever
since many processes ultimately need to copy very little of the memory
context, particularly in the typical fork/exec paradigm.) You wait
until it's needed instead of doing the copying in advance in the hope
that little will really need to be copied (of course, the cost at that
point is a little higher since noticing the process needs a copy later
generally requires managing a page fault.)
Shared text is a thread-like notion, but only one part of the picture.
Explicitly shared memory is similar although making the implementation
as efficient as you can when the process says in advance "I'm sharing
everything!" is probably impossible. In the first place it still
implies the sub-process has its own page tables as some things are
shared and some things are not (on some systems it is possible to
share everything in one shot and have the O/S notice that, again,
thread-like, but there's more.)
Something worth considering if you're still confused is the signal
context. In a thread you're guaranteed that all signal handling set-up
will be shared. Changing the signal handler for one thread changes it
for all the threads. There's no way, for example, to have only one
thread responsible for handling SIGINTR, they'll all see it (tho all
but one can deduce they are not the one to handle this signal and go
back to what they were doing, but that's application code not O/S code
as it is/can be with processes.)
Some consider that a bug, some a feature.
See Aral, Gertner and Langerman's article in the past (San Diego)
USENIX on this topic. Also Mach and Sun's documentation. There are
other good references.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
David Collier-Brown
In article <106...@sun.Eng.Sun.COM>, ne...@sun.Eng.Sun.COM (news)
writes:
| What kinds of things should be in the GNU Kernel?
| Security: Provably secure(A1)?
In article <11...@vsi.COM> fri...@vsi.COM (Stephen J. Friedl) writes:
| Who would ever believe that RMS would come up with an A1 system?
| Steve :-)
I'll believe he could (I've seen his work, and its a well-understood
area, if difficult). What I don't believe is that he **would**. RMS
fits the "cooperative workgroup" universe better than the "tiger team"
one.
--dave (a former tiger) c-b
John Macdonald
>...
>
>The supposed advantage of a thread is that it's cheap to create one,
>even compared with setting up copy-on-write for a fast fork(). The
>obvious disadvantage is that the shared data space requires use of
>concurrency controls among the parallel threads (e.g. monitors).
>Unfortunately, really good concurrency controls don't seem to exist
>at present. Until someone devises a slick way to do this right in
>high-level languages, I'll continue to prefer separate processes and
>explicit data sharing.
>
>By the way, Burroughs came close with their B5x00 and B6x00 series
>Extended Algol implementations.
A slick way to do this right has been devised more than ten years ago.
This method originated with the (Waterloo) Thoth Operating System [1],
and has since been used and extended in a number of other systems (perhaps
most notably the Stanford V system[2] [and maybe Mach too, but I don't know
about that]). This method uses small fixed size messages sent between
processes using primitives send, receive, and reply. The sender blocks
until the receiver accepts the message AND replies to it. This same mechanism
can be used between any two processes, whether they are "threads in the
same address space" (processes in the same team in Thoth terminology),
or totally different processes.
Processes within a team can use many different ways of organizing their
shared memory, but the message system should be used to co-ordinate transfer
of control of a logical area of memory. This provides the co-ordinating
capability of a message-based system, without requiring the overhead of
having ALL data interchange be done through messages. (An additional
feature was a block transfer between processes in different address spaces
between the receive and reply, allowing reasonable data throughput even
when the processes are not on the same team.)
This mechanism allows for a huge amount of non-kernel implementation of
system capabilities, can provide for many capabilities within the
message mechanism (e.g. streams, ioctl, remote systems, file system
switch, spooling servers, it slices, it dices, it makes its own gravy :-)
using a single mechanism in a rather elegant clean fashion.
=== References (sort of) ===
[1] "The Thoth System: Multi-Process Structuring and Portability", by
David R. Cheriton; published by Elsevier/North Holland; ISBN 0-444-00701-6
(There were also a number of papers produced, but I don't have references
for them.)
[2] (Again, I don't have specific references, but there have been many
papers reporting on various aspects of the V system in numerous journals.)
--
John Macdonald
dave l smythe
I expect that he would want it to be easily left out -- the server idea
would be helpful in that regard.) I say this because I seem to remember
him saying something of the sort (perhaps in a GNU bulletin?)
As for features/incompatibility, why not ask a few people that HATE UNIX
why they hate it? (don't look at me!) That might prompt some discussion
that wouldn't necessarily occur otherwise.
Personal items (I'm not an OS guru):
the fair-share scheduler might be useful, (only if used as a multi-user
OS (?))
fast task-switches
support for real-time
Stephen Martin
having to mount a whole directory.
--
___ ___ ___ ___ _ _ ___
/__/ / / /__ / /\ / / _ Stephen Martin, Boeing Canada, Toronto.
/__/ /__/ /__ _/_ / / /__/
Nuke the Raisins
UUCP: sma...@iemisi.UUCP
{uunet|suncan}!jtsv16!marsal1!iemisi!smartin
Jay Plett
- In article <4...@crdgw1.crd.ge.com>, bar...@crdgw1.crd.ge.com (Bruce G. Barnett) writes:
- > Long filenames are great. I use filenames all the time to hold
- > extra information, which allows database queries using shell meta-characters.
-
- storing information is what a filesystem is for.
- if you want to use regular expressions, put the information
- in a file. don't complicate a universal mechanism like
- the file-system name space just so you can be lazy about
- selecting filenames.
Oh for cryin' out loud.
Tools are for using. One of the best measures of a tool's
success is the number of ways users can find to use it which
were never anticipated by its maker.
Barnett is creative, not lazy.
John F. Haugh II
> I'd say go ahead and leave
>/etc/passwd the way it is, but try to come up with a simple password-
>checker to make sure people don't use password=account-name couplets.
You can't make it to B1 secure with non-privileged user readable
encrypted passwords.
The Orange Book clearly outlines the requirements regarding
publically readable encrypted data. I encourage anyone making
security decisions to read the book.
--
John F. Haugh II +-Button of the Week Club:-------------
VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word,
InterNet: j...@rpp386.Cactus.Org | and it's BLUE."
UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
John F. Haugh II
>In article <106...@sun.Eng.Sun.COM>, ne...@sun.Eng.Sun.COM (news) writes:
>
>Perhaps. This would solve the bits-in-st_flags problem.
It would also solve the problem of being compatible with UNIX ;-)
Any secured filesystem solution must address backwards compatibility.
Stealing bits from st_mode [ there is not a st_flags field in a struct
stat ] is only going to wreck havoc on a large body of software which
knows about st_mode bits.
>> Get rid of root?
>
>Hmmm. Go to something like DEV:path as per VMS/AmigaDOS/MSDOS/...?
>Handy, particularly if you have assigns. But too many incompatibilities.
I think he meant getting rid of UID == 0 being a privileged user.
Again, this an Orange Book requirement. It also makes much sense.
Programs should have privilege, not users. The ability to access
a program can then be limited to a collection of users or groups.
Or use /etc/group to allow some group of users to newgrp to an
administrative account. The group ``dumpers'' might exist for
persons taking file system dumps. All of the dumpable devices
would then have file group ``dumpers''. Root wouldn't have to
be used for dumps any longer.
>> Security monitors? Auditing?
>> Provably secure(A1)?
>
>Not possible, I think, with the resources GNU has.
GNU, as distributed directly from FSF, might exist in some
secure form. As hacked on by some random collection of bodies
before reaching me will never be considered trustable.
Jim Frost
Fork causes duplication of the data area and stack area. Thread would
only duplicate the stack area, the data area would be shared. Note
that whether or not you do real copies or copy-on-write is pretty much
implementation-dependent.
The difference, that of shared data space (and often that creation is
cheaper -- possibly *much* cheaper -- than fork) makes threading a
powerful tool.
jim frost
software tool & die
ma...@bu-it.bu.edu
Jim Frost
|In article <10...@smoke.BRL.MIL> gw...@brl.arpa (Doug Gwyn) writes:
|This method originated with the (Waterloo) Thoth Operating System [1],
|and has since been used and extended in a number of other systems (perhaps
|most notably the Stanford V system[2] [and maybe Mach too, but I don't know
|about that]). This method uses small fixed size messages sent between
|processes using primitives send, receive, and reply. The sender blocks
|until the receiver accepts the message AND replies to it.
|This mechanism allows for a huge amount of non-kernel implementation of
|using a single mechanism in a rather elegant clean fashion.
MINIX, a small Version 7 implementation of UNIX, uses a
message-passing kernel as well, and has processes handle just about
everything except scheduling. Given that MINIX is a teaching tool,
we may see more of this showing up (see _Operating Systems: Design
and Implementation_, A. Tanenbaum). It certainly has an elegant
design, and since you get to futz with source, MINIX is an excellent
system for teaching.
There are problems with message-passing; it's usually a bottleneck,
creates overhead on every call (even those which you would like to
have almost no overhead), and is often difficult to move to
multiple-processor systems. All of these problems can be corrected,
but you screw up the elegance of the system.
David Kuder
And in article <11...@vsi.COM> fri...@vsi.COM (Stephen J. Friedl) writes:
>> Security: Provably secure(A1)?
>Who would ever believe that RMS would come up with an A1 system?
Just to amplify on this. Richard Stallman (RMS), the founder of
the FSF and GNU, really hates things that limit the free exchange of
information. Much of what security does limits free exchange of information,
leads to feelings of ownership of programs, etc. Now security also protects
information from the malicious but in a perfect world there is no reason to
be malicious. Lack of perfection in the world hasn't stopped RMS in the past.
RMS has been known to complain when login ids were required. GNU will most
likely be very open with the corresponding lessening in security.
Kenneth Almquist
> Networking: NFS? RFS? Something better?
Something better. I would like to see a distributed file system along
the lines of the Sprite file system or the Apollo Domain file system.
The features I want are:
1) A single global name space. A file should have the same name
regardless of which system it is being accessed from.
2) The semantics of file operations should be the same regardless
of whether the file is local or not.
3) If a file cannot be accessed because the system it is on is
down or unreachable, the user should be notified quickly.
4) The ability to replicate file system that change infrequently,
to increase availability.
Kenneth Almquist
Peter da Silva
> I don't think there should be a namesystem root. I recently sent DMR some
> notes about a new concept that would permit us to get rid of namesystem root,
> among other things. I don't know whether anything will come of it..
AmigaDOS doesn't have a namesystem root. It's annoying... one of these
days I'm gonna implement a ROOT: handler and get the best of both worlds.
Peter da Silva
> Fork causes duplication of the data area and stack area. Thread would
> only duplicate the stack area, the data area would be shared.
An efficient version of threads would not even duplicate the stack area...
instead the child would have a virgin stack, wit its starting address
passed from the parent. It's highlt desirable to make thread creation
a cheap process.
Stan Switzer
> James Buster asks what kinds of things should be in th GNU kernel:
>
> > Networking: NFS? RFS? Something better?
>
> Something better. I would like to see a distributed file system along
> the lines of the Sprite file system or the Apollo Domain file system.
> The features I want are:
>
> 1) A single global name space. A file should have the same name
> regardless of which system it is being accessed from.
I really don't understand why people just assume that this would be a
good idea. Do they _really_ mean _global_? Do they mean that no
matter where I am in the world, a given path will always give me the
same file? I wonder what /bin/sh is, then.
It seems to me that there should be some space in which files can be
globally and unambiguously identified. The structure of this name
will most likely reflect the hierarchy of naming administrations under
which it is registered rather than anything particularly meaningful.
As a separate matter, there should be a space or spaces in which files
are named in a manner convenient to the users and applications. This
naming scheme might very well vary from system to system or even from
user to user on the same system.
One should also consider, in this last regard, that there are
organizations other than hierarchical worth considering (attribute
based naming, for instance).
> 3) If a file cannot be accessed because the system it is on is
> down or unreachable, the user should be notified quickly.
In many cases it will be difficult to find a user. I am thinking of
intrinsicly graphical, multi-windowed user interfaces here. Would
logging an error message on the "console" be sufficient?
We have got to figure out how to stop constantly emulating terminals.
Maybe a "visual shell" is in order. What are the implications on
external program interfaces? Will argv[] and the fd vector be a
sufficient mechanism, or will something entirely different be
necessary (for instance service port capabilities)? Let's plug
programs (modules) together like tinker-toys (down with syntax, I want
to program using pictures and gestures!).
Stan Switzer s...@ctt.bellcore.com
Leslie Mikesell
>> Long filenames are great. I use filenames all the time to hold
>> extra information, which allows database queries using shell meta-characters.
>storing information is what a filesystem is for.
>if you want to use regular expressions, put the information
>in a file.
Are you suggesting that your filenames *don't* store any information?
Besides the obvious intent of the name, there is the advantage for
database usage that some directory operations are atomic. That is,
you will normally never be able to access a filename in an inconsistent
state. You cannot say the same for the contents of the files unless
explicit locking is done.
Les Mikesell
Evan Bigall
>I too *HATE* arbitrary limits, it's so restrictive!
>
>Why don't make the filename length dynamic!?
If name lengths are dynamic with no upper bound how large a buffer would you
allocate for them in programs?
--
Evan Bigall, Plexus Computers, San Jose, CA (408)943-2283 ...!sun!plx!evan
"I barely have the authority to speak for myself, certainly not anybody else"
Erik Murrey
>>How about scheduling processes on a per-login basis, rather than
>>per-process. I.e. a user has a certain quantum that is divided
>>between all the processes he starts. (It should be configurable,
>>and maybe even adjustable on the fly by a privileged user.) This
>>would keep one user from starting sixteen compiles and bringing a
>>system to its knees.
>
>Fair to users, maybe. How would you handle daemons? Is each daemon its
>own process group? Or can they be grouped together somehow?
How about having separate scheduler queues ala OS/2 (ugh!). Make a
queue for daemons, a queue for interactive processes, and a queue for
real-time processes. Each processes within that queue can also elect
(or be assigned) a priority within that queue, similar to a nice
value.
The theory is that real-time queue gets acted upon immediately
following a condition that was blocking it. Processes within that
queue are very immune to time-slice restrictions, except for other
processes within that queue. (Watch out for tight loops...)
The interactive process queue will be acted upon immediately following
any condition that was blocking it, such as terminal I/O, disk I/O,
etc. This provides the response necessary for user interfaces, and
medium speed communications programs.
The daemon process queue will only run when all other processes are
blocked on I/O, or when the processes has been blocked by an
interactive process for some absurd amount of time.
Of course, all of the above would need fine-tuning, and more rules....
... Erik
--
Erik Murrey /| // /~~~~/ | /
MPX Data Systems, Inc. / | / / /____/ |/
er...@mpx.com / / / / /| Data Systems, Inc.
{vu-vlsi, bpa, cbmvax}!mpx1!erik / / / / |====================
Root Boy Jim
? As you seem to suspect, a "thread" has its own stack and state but
? shares code and data with other threads, whereas a "fork" has its
? own stack, state, and data but shares just the code with the other
? branch of the fork.
Hmmm. I've been saying we needed this all along. See next comment.
[rearranging a bit]
? By the way, Burroughs came close with their B5x00 and B6x00 series
? Extended Algol implementations.
EXEC-8 (Univac 1108) has `activities'. I believe you loaded a register
with an execution address and did an executive request to (yes...) FORK.
The parent continued inline, and the child went where the register pointed.
The `activity name' was either returned in another register or available
thru another executive requests. All code/data space was shared. There
was no stack.
? The supposed advantage of a thread is that it's cheap to create one,
? even compared with setting up copy-on-write for a fast fork(). The
? obvious disadvantage is that the shared data space requires use of
? concurrency controls among the parallel threads (e.g. monitors).
? Unfortunately, really good concurrency controls don't seem to exist
? at present. Until someone devises a slick way to do this right in
? high-level languages, I'll continue to prefer separate processes and
? explicit data sharing.
Concurrency controls? On the data? On the u-block/proc-entry? Elsewhere?
EXEC-8 pretty duplicated most of it's PCT (u/proc) entry. After all,
they really are separate processes, they just happen to share the
same address space, uid, gid, etc.
As for the higher-level semantics, each thread needs to know it's
`instance number' (starting from zero) as well as its pid. All global
data used by threads is an array indexed by the instance number. The
stack would be duplicated, so local variable could be used as usual.
It would seem somewhat inconvenient to have to keep passing the
instance number to all called procedures tho. Seems like a language
extension might need to be defined.
And speaking of language extensions, how about guaranteeing that
unwind-protect, catch/throw, condition-case, etc, work in GNU C?
Let me take another guess at what you mean about concurrency controls.
How about semaphores. *REAL* semaphores, as Dijkstra intended them.
Something understandable. Something universal. I don't know why people
keep ignoring these things, as far as I know, they handle every
problem, multiprocessor, interrupt, critical sections, everything.
Root Boy Jim is what I am
Are you what you are or what?
Root Boy Jim
? Basic unix rwx built-in, plus per-filesystem switch controlling support
? for setuid bits on that fs (allowing user-level mounts of removable media).
One thing I'd like to see is an rwx triplet that applied to root as
well. That is, if I `chmod r-w' on a given (source) directory, root
couldn't add or delete files in it until he `chmod r+w'ed it.
I would like to see filesystems be able to flip from RO to RW without
un-/re- mounting them. Of course, you'd have to wait for RW activity
to stop, but readers could keep right on reading without having to
close and reopen any such files.
I'd like to see better access to the fs innards. A Root Boy should be
able to mknod a directory into a file, edit it (dired :-), and mknod
it back to a directory. Well, maybe not, but something like it. How
many times have you wanted to do something with inode 347 (like relinking
it when fsck barfed) but couldn't?
I'd like to see better control of mtimes. Often, I care most about
the time the data was last changed. The file is just the container.
Thanks to Mark Weiser, who alerted me to that fact.
But most of all, I'd like to see it soon. GNU will change and evolve,
perhaps drastically in its first incarnations. We won't be able to
have all the whiz-bang features immediately, so perhaps it isn't
quite useful to speculate on what they might be. At this stage, we
need some unifying principles that will carry us far, such as,
`every object will be a file descriptor', or `the kernel will be
small and do message passing', or `scheduling and filesystem I/O
will be done by user-level processes'. Some good ideas from both
flavors of UNIX, MACH, LOCUS, etc already exist. The hard part
is to put them all together into a unified framework.
? Les Mikesell
Bruce G. Barnett
>storing information is what a filesystem is for.
>if you want to use regular expressions, put the information
>in a file. don't complicate a universal mechanism like
>the file-system name space just so you can be lazy about
>selecting filenames.
I didn't complicate anything. I just used Unix in a convenient manner for me.
If you consider that lazy, you have a warped idea of what computers are
supposed to do. I also resent your implication that I am lazy.
In fact, it took several interations until I came up with a naming convention
that was most convenient for my application.
As an example, I was collecting accounting information across several machines.
The filenames were something like
<machine><report>-<option>.<time_period>
where
<machine> was a hostname or ""
<report> was some accounting type program
<option> was a list of zero or more options
<time_period> was a value like "Apr_28", "Apr_28.Week", "Apr_28.AM"
Now if I wanted to look at all "sa" reports for all machines for
all mornings in April, I can type
more *sa-*Apr*.AM
If I want to print out all weekly summaries for machine mymachine,
I can type
print mymachine*WEEK
Of course there are dozens of ways to make this more efficient
from an operating system viewpoint. My main goal was to provide
the needed functionality as quickly as possible, and long filenames
make my life a lot easier.
--
Bruce G. Barnett <bar...@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]>
uunet!crdgw1.ge.com!barnett bar...@crdgw1.UUCP
John F. Haugh II
>instead the child would have a virgin stack, wit its starting address
>passed from the parent. It's highlt desirable to make thread creation
>a cheap process.
You have to duplicate the stack - even if you only duplicate it via
a copy-on-write mechanism.
As you unwind stack frames in either thread, you would reach a point
where you start trashing the stack frames of the either thread.
Systems Programmer
The memories have gotten a bit fuzzy with time, but in TSS/360 it
was possible for the system administrator (as opposed to the systems
programmer or the operator) to join (was that the right command?) users
who were "subadministrators" (or some such) who could, in turn, join
ordinary users to the system. Subadministrators could take a conside-
rable load off the system administrator's back in handling ordinary
users' account/logonid maintenance. Subadministrators, however, could
join *only* ordinary users (if I remember right), not other adminis-
trators of any sort.
I take care of five computers running three operating systems and
only one is UNIX (this one :-). It would be a big help to me if client
departments could take care of the routine stuff, provided they had no
way to add privileged users, i.e. nobody added to certain groups like
staff, wheel, operator, and nobody added with certain uid numbers.
Perhaps a facility for handling multiple, limited-function, sub-
/etc/passwd equivalent files would be a method, though I'm sure there
are others and probably better ones. Obviously, limitations would
have to apply to the rest of the /etc/passwd-style information as well.
Scott Bennett
Systems Programming
Northern Illinois University
DeKalb, Illinois 60115
**********************************************************************
* uucp: {alliant,encore,laidbak,oddjob,sequent,uokmax}!\ *
* anlams!niuvax!sys1 *
* Internet/uucp: sys1%niuva...@mcs.anl.gov *
* BITNET: A01SJB1@NIU *
*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*
* "Some people call them 'cars' or 'trucks'; I call them 'dimen- *
* sional transmogrifiers' because they change *three*-dimensional *
* *cats* into *two*-dimensional ones." --F. Frederick Skitty *
**********************************************************************
Leslie Mikesell
>The supposed advantage of a thread is that it's cheap to create one,
>even compared with setting up copy-on-write for a fast fork(). The
>obvious disadvantage is that the shared data space requires use of
>concurrency controls among the parallel threads (e.g. monitors).
That's what I thought, but I can't see where it would be useful, except
perhaps to make up for certain OS functions that might be lacking
like the ability to cheaply determine that no I/O is pending on any
of several channels so you can continue doing some work without needing
a new thread. Wouldn't there be a problem with static data in
library routines (or anywhere else)?
Les Mikesell
Leslie Mikesell
>? Les Mikesell
> Root Boy Jim is what I am
> Are you what you are or what?
I suppose it is a bit antisocial to omit the usual .signature explaining
who I work for and why I don't speak for them. I work for The American
Farm Bureau and I don't speak for them because they don't pay me enough.
ag...@xenurus.gould.com
I missed the original post (was away for a week).
Was somebody seriously asking for a wishlist?
If so, here's a limited list, items deliberately chosen to be simple,
obtainable, yet just beyond present day UNIX:
==> The kernel should have no knowledge whatsoever of file types,
except for one, and only one, executable format.
IE. there should be none of that COFF/adb/SOFF stuff in
exec().
There should be system calls to read text, code, from a file,
change that code to be execute permitted and read-only, and then
branch to that code, removing (otionally) the segment or stub that
bootstrapped. With these primitives arbitrary executable file formats
could be implemented, in user space.
==> "Real time" scheduling features: fixed priority scheduling, etc.
A scheduler that uses only strict priority as a means of deciding
what process to run next; this is combined with a "priority migration
policy" to produce any type of scheduling you want.
==> Asynchronous I/O:
True asynch I/O operations as underlying primitives;
synch I/O implemented as
ioid = asynch_read(fd,buf,nbytes);
asynch_iowait(ioid);
rather than the abominable approach of implementing asynchronous
I/O via IPC to a limited number of kernel processes that do synch I/O.
==> High res clock
Peter da Silva
> Besides the obvious intent of the name, there is the advantage for
> database usage that some directory operations are atomic. That is,
> you will normally never be able to access a filename in an inconsistent
> state. You cannot say the same for the contents of the files unless
> explicit locking is done.
I've been thinking about this statement, but it still does not make any sense.
If you do a read or write that does not span block boundaries it should be
atomic. So a binary read or write that's a power of two bytes in length should
have no problem. Certainly I don't think I've ever seen a problem with utmp.
Or with directories, for that matter... which after all are just files with
16-byte records in them (except for on BSD, and I think they still don't
cross block boundaries).
George Robbins
> I would like to see a way to NFS mount or remotely link a specific file
> without having to mount a whole directory.
Have you tried it? Seems to work fine on DEC's Ultrix implementation of NFS.
The "mount point" must be a directory, but it turns into a "file" when a
remote file is mounted on it.
I haven't the faintest idea whether it is "supposed" to work or not, I was
a bit surprised when I discovered this "feature" by accident.
--
George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!g...@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
Gil Pilz@Eng@Banyan
>
>> Networking: NFS? RFS? Something better?
>
>Something better. I would like to see a distributed file system along
>the lines of the Sprite file system or the Apollo Domain file system.
How about coming down to earth a little bit here ? What's the point
of anyone having a GNU system in the first place ? Are you really
looking for the hottest Unix derivative on the planet ? No, you just
want a decent Unix system that's FREE. Free to obtain, free to
distribute, free to play with. I think spending a lot of effort trying
to keep up with or shoot ahead of the latest & greatest is a mistake.
How many people does the FSF have anyway ?
What's wrong with taking MACH, maybe changing it a little just to feel
good about it, and putting it out ? (note I have not the foggiest
idead of the state of relations between the MACH people and the FSF)
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Gilbert W. Pilz Jr. g...@banyan.com
Banyan Systems Inc. (617) 898-1196
115 Flanders Road
Westboro, MA 01581
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Peter da Silva
> In article <43...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
> >An efficient version of threads would not even duplicate the stack area...
> As you unwind stack frames in either thread, you would reach a point
> where you start trashing the stack frames of the either thread.
This assumes you can unwind the stack. You're assuming that the thread()
call looks like fork(). That's not efficient. You need something like:
pid = thread(initial_PC, final_PC, initial_stack_size, maximum_stack_size, priority);
Used like so:
void do_raytrace();
void cleanup();
int trace_pid;
trace_pid = thread(do_raytrace, cleanup, 256, 1024, 5);
This creates a new stack for the thread (256 bytes if it's growable, 1024
bytes otherwise), pushes the address of 'cleanup' on it, and jumps to the
start routine: do_raytrace(). Cleanup looks like this:
cleanup()
{
thread_exit();
}
This avoids duplicating (or potentially duplicating) a large amount of data,
and avoids having to swap MMU contexts for the new stack when you enter the
thread. The entire MMU context of the parent and child threads can be the
same.
John Hall
kernel file-path parser. I think it is silly to have to re-compile your
kernel each time you want to add a new functionality (for example, NFS, or
Sun's NSE). A method for user programs to map their functions or resources
into UNIX filename-space would be revolutionary.
Device driver interfaces, distributed files, and resources all could
be implemented as servers, and each server could handle it's own security,
resource allocation, etc. dynamically. Also, you could have servers
do wildcard parsing. Think of all the traverse(), parse_path(),
search_file(), routines that would obsolete.
A trivial example would be a server that made an archive look like a
directory. You could copy files in and out, list, do as you please; and
when you were done, use the regular name to move, backup, etc. the archive.
You could have a database-type server that automatically handles file
locking.
I hope people can take this idea and make something workable out of it.
My intuition says it is a good one, and I know it would have made life
much easier for me on a number of occasions.
As always, Thank You for Your Support.
--
John "Down Ball" Hall > Volleyball isn't just a sport ... it's a religion! <
Applied Microsystems Corp. | Disclamer: "Did I say that??? My mind must |
Voice: (206) 882-2000 x654 | be out to lunch. I hate when that happens!" |
UUCP: uunet!amc!jhall | Ollie's Disclaimer: "I don't recall..." |
MFHorn
>In article <SMARTIN.89...@iemsun.dhc> sma...@iemsun.dhc (Stephen Martin) writes:
>> I would like to see a way to NFS mount or remotely link a specific file
>> without having to mount a whole directory.
>
>remote file is mounted on it.
>
>I haven't the faintest idea whether it is "supposed" to work or not, I was
>a bit surprised when I discovered this "feature" by accident.
I too was surprised to find it work (SunOS 4.0 mounted a DG/UX 4.02 file).
But if you stop and think that all diskless clients 'mount' a swap _file_
from the server, it makes some sense that it should work.
--
Andy Rosen | aro...@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031 | ulowell!arosen | learned how to make it
Lowell, Ma 01854 | | talk" -Thunder Road
RD in '88 - The way it should've been
Brandon S. Allbery
+---------------
| In article <106...@sun.Eng.Sun.COM> bitbug (James Buster) writes:
| }Security: ACLs? Get rid of root? Security monitors? Auditing?
| } Provably secure(A1)?
|
| Better security is always a good thing. Security's not my forte, so
| I'll leave it alone.
+---------------
...provably secure? From RMS??? You dream. (On the other hand, the lack
of security that RMS prefers would be the biggest stumbling block in getting
people to *use* GNU... whereas I, for one, would like to see a lot of tin
gods topple when GNU becomes the industry standard. [ 1/2 ;-) ]
+---------------
| and maybe even adjustable on the fly by a privileged user.) This
| would keep one user from starting sixteen compiles and bringing a
| system to its knees.
+---------------
...I think I'm in trouble. ;-)
+---------------
| }Virtual Memory: Should GNU run on non-VM machines? Algorithm ideas?
| } How general (map *everything* into VM space, like Multics)?
| } Shared libraries?
|
| I like the SunOS virtual memory concept (minus the current crop of bugs, of
| course). If you're writing a Real Operating System, why worry about machines
| that won't support virtual memory. Hell, by the time Gnu is ready, non-VM
| machines will probably be a thing of the past anyway. Shared libraries
| are good. Shared instruction space (text?) is another good idea, that can
| help save on memory requirements for often-used programs.
+---------------
Aside from unburied corpses like ncoast, non-VM machines already *are* a
thing of the past. Heck, any 386 has VM.
+---------------
| }Networking: NFS? RFS? Something better?
| } Interfaces: Streams? TLI? Something better?
| } TCP/IP? OSI? SAA/SNA:-)?
| } RPC Services? What kind?
|
| Something better. But don't ask me what. NFS is OK, but it has problems.
| You would want to support TCP/IP, at least at first (maybe using the BSD
| code), but OSI is probably the way to go. SNA makes me gag. (Actually,
| all of IBM makes me gag. :-)
+---------------
OSI, with a TCP wrapper for compatibility with present systems.
I'd prefer Streams. REAL Streams, not the botch that was added to System V.
(Or did V8 live in vain?)
Network file systems: something better than NFS. Something better than RFS.
I suspect it has to be stateful; file locking effectively ended the reign of
stateless NFS. But RFS can't handle non-UNIX filesystems *transparently*.
(On the other hand, the File System Switch helps to cure that.)
I advise mixing and matching from NFS and RFS, combined with anything else
you can come up with that would *work* (no kluges, please!!!).
+---------------
| }Overall Design: What nice ideas from other OSes could we use?
+---------------
I'd like to see a generalized namei() which supports environment variables.
This is upwardly compatible with DEC-style logical names and also provides
something similar to symlinks -- with the kind of multiple-universe stuff
that many Unixes now have (useful if Gnu itself diverges in any appreciable
way from Berkeley Unix, and also useful to us die-hard System V users).
+---------------
| }How about this? Make everything a user process which serves
| }a resource to a client. Resources include the CPU (scheduler),
| }memory (VM), disk (file system), network (sockets, etc),
| }serial lines (terminal handlers), etc. Each server determines the access
|
| Excellent idea! Promotes modularity, and allows flexibility. Almost a
| plug-and-play operating system. One problem, though: there would have
| to be some sort of privilege level system, so that the resource handlers
| can do things like write other user's memory, directly access devices,
| re-map memory, etc. And you would have to provide at least minimal
| functions in each module in the initial release. Not everybody is
| an OS developer.
+---------------
"Minimal functions"? I think that what'll be provided is the set of servers
which implements standard GNU (and, obviously, with source -- well-commented,
I hope (hint, hint!). --Multiple copies of these should be able to run at
the same time. OS compatibility then becomes a non-issue; if a System V-er
gets an account, start up the System V-emulating servers, which will be
paged out unless and until that user makes a System-V-style request.
++Brandon
--
Brandon S. Allbery, moderator of comp.sources.misc all...@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery ncoast!all...@hal.cwru.edu
Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
Doug Gwyn
I'm not familiar with AmigaDOS, but the goal is not just to get rid of
a root for the namesystem, it's to make such a root unnecessary.
(My scheme actually provides, as a special case, a way to obtain local
top-level handles, but there is no inherent global hierarchy.)
Doug Gwyn
>Wouldn't there be a problem with static data in library routines
>(or anywhere else)?
There sure would be. This issue came up several times while debating
what the specifications should be for some of the standard library
functions. Unfortunately, existing practice in some cases is unsuitable
when parallel threads of computation are used.
We recently tracked down a mysterious bug in some of the daemons on a
Gould UTX-32 system; the daemons were using syslog() which in turn used
vfork(), BSD's thread-creation mechanism, then invoked sigvec() for the
first time; UTX-32 establishes a signal catcher stack etc. the first
time that sigvec() is invoked, and it uses a static "first time" flag
to determine whether this needs to be done. The result was that the
child branch of the vfork() worked fine, but after it terminated the
parent branch no longer actually had a valid signal catcher even though
the library code thought it did (due to the shared flag having been
updated).
One of the reasons the biggest names in computer science have spent so
much time on the theory of concurrent processes is that it's a really
hard problem.
Doug Gwyn
>No, you just want a decent Unix system that's FREE.
Right on!
I think there are three classes of enhancement "wish list" items
that people have been suggesting:
- blue-sky research projects
- significant known developments that would be a shame to
pass up, if one is going to build an OS from scratch anyway
- minor glitches in historical UNIX that could easily be fixed
The last-mentioned category seems appropriate for GUN, the second
category needs to be thought about, and the first category is asking
too much.
Barry Shein
From: l...@chinet.chi.il.us (Leslie Mikesell)
>That's what I thought, but I can't see where it would be useful, except
>perhaps to make up for certain OS functions that might be lacking
>like the ability to cheaply determine that no I/O is pending on any
>of several channels so you can continue doing some work without needing
>a new thread. Wouldn't there be a problem with static data in
>library routines (or anywhere else)?
One obvious use of threads is on a parallel machine where each thread
gets its own CPU (if available, but that's a resource scheduling
issue.) The ability to start up threads quickly and cheaply is
fundamental to being useful since waiting as long to get started
(latency) as it would have taken to do the computation on one
processor is useless.
Consider the following simple example:
Read large array
Partition array for N CPUs
Start a thread on each partition searching for some value
If it takes 1 second to search on a uni-processor it had better take
less than 1/10 of a second to start each of 10 threads searching.
Of course, this doesn't mean that the current implementations of
"threads" are correct or even necessary. It just means what it means.
In particular consider gigabytes of memory and hundreds of CPUs
available. Most unix fork() implementations can't begin to take any
advantage of such configurations, yet they're becoming available
rapidly.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
Steve Lamont
<As quoted from <4...@ladcgw.ladc.bull.com> by fr...@ladc.bull.com (Frank Mayhar):
<+---------------
<| } How general (map *everything* into VM space, like Multics)?
<| } Shared libraries?
<|
<| I like the SunOS virtual memory concept (minus the current crop of bugs, of
<| course). If you're writing a Real Operating System, why worry about machines
<| that won't support virtual memory. Hell, by the time Gnu is ready, non-VM
<| machines will probably be a thing of the past anyway. Shared libraries
Like the Cray Y-MP or Cray 3? IMHO, if you wish to be a player in the
supercomputing game, you'll have to consider systems which don't support
virtual memory. How about enormously parallel machines with a large
number of processors but a small amount of physical memory per
processor? I suspect that non-virtual memory machines will be around
for much longer than any of us care to think about.
--
spl
Steve Lamont, sciViGuy EMail: s...@ncsc.org
North Carolina Supercomputing Center Phone: (919) 248-1120
Box 12732/RTP, NC 27709
John F. Haugh II
>If you do a read or write that does not span block boundaries it should be
>atomic. So a binary read or write that's a power of two bytes in length should
>have no problem. Certainly I don't think I've ever seen a problem with utmp.
>
>Or with directories, for that matter... which after all are just files with
>16-byte records in them (except for on BSD, and I think they still don't
>cross block boundaries).
One very important difference. namei() returns a pointer to a LOCKED
inode. The modification to the directory is very atomic, whereas the
modification to a regular file is not. The file is not locked automagically
as is the case with directories.
Ashok Yerneni
>
>Device driver interfaces, distributed files, and resources all could
>be implemented as servers, and each server could handle it's own security,
>resource allocation, etc. dynamically. Also, you could have servers
>do wildcard parsing. Think of all the traverse(), parse_path(),
>search_file(), routines that would obsolete.
a typical problem with server based implementations is the additional
layer of software that slows down the overall performance. A typical example
is the comparison of performance between kernel based windowing systems like
SUN view and server based systems like Xwindows.
>
> As always, Thank You for Your Support.
>
>--
>John "Down Ball" Hall > Volleyball isn't just a sport ... it's a religion! <
>Applied Microsystems Corp. | Disclamer: "Did I say that??? My mind must |
>Voice: (206) 882-2000 x654 | be out to lunch. I hate when that happens!" |
>UUCP: uunet!amc!jhall | Ollie's Disclaimer: "I don't recall..." |
Ashok Yerneni gatech!stiatl!ashok
Sales Technologies, Inc
3399 Peachtree Rd, NE
Atlanta, GA
off (404) 842-9319
res (404) 634-4398
Root Boy Jim
? Certainly I don't think I've ever seen a problem with utmp.
There is no problem with utmp because noone tries to write in the
same place at the same time. It would seem that small writes within
a block *would* be atomic. The trick is to pick a small enuf number
on the right boundary and hope that this is true in all cases.
Directory writes are atomic because they are done by the kernel.
BTW, I agree with you that threads need not duplicate the stack.
It doesn't seem to make much sense what happens when a thread
returns/exits. However, I would rather see the kernel/library
push the address of thread_exit on the stack. Eliminates one argument.
? Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
? Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
? Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Peter da Silva
> modification to a regular file is not. The file is not locked automagically
> as is the case with directories.
Yes, I realise that this would be a problem with read-modify-write. but
the application in question didn't sound like it needed that... all it
needed was append (supported) and atomic reads/writes (supported) to maintain
consistency.
Can you see any case where a file open with O_APPEND could get out of
sync, when you're doing reads and writes that are known to be atomic
(that is, don't cross block boundaries)?
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Usenet file owner
How about a decent scheduling algorithm? BSD's just doesn't cut it
(haven't tried System V's yet). Something that lets 'nice'd jobs
still get some CPU once in a while....
+---------------------------+------------------------+
| Anton Rang (grad student) | "VMS Forever!" |
| Michigan State University | ra...@cpswh.cps.msu.edu |
+---------------------------+------------------------+
Frank Mayhar
>As quoted from <4...@ladcgw.ladc.bull.com> by fr...@ladc.bull.com (Frank Mayhar):
>| course). If you're writing a Real Operating System, why worry about machines
>| that won't support virtual memory. Hell, by the time Gnu is ready, non-VM
>| machines will probably be a thing of the past anyway. Shared libraries
Melinda Shore at Mt. Xinu also brought up this question (in email). Here's
my reply.
Actually, IMHO, a Cray is a very poor choice of hardware to run a general-
purpose OS on. As I see it, you would want the Cray to run a minimal kernel
(primarily consisting of a scheduler) that accepts compute-bound jobs from
a client machine running some general OS, and executes them. Basically,
a high-speed backend that runs those cpu bound jobs that are so hard on
general-purpose OS's, and that's *all* it does. The general-purpose OS
(running on a virtual memory machine :-) performs task scheduling, memory
allocation, job queueing, etc, and hands the jobs to the Cray.
Disclaimer: I have no direct knowledge of how Crays work. When I made my
comment, it was in reference to general-purpose operating systems. And, no,
I don't think that a Cray has any business running a Real Operating System.
(Half :-)
--
Frank Mayhar ..!uunet!ladcgw!frank (fr...@ladc.bull.com)
Bull HN Los Angeles Development Center
5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
Guy Harris
>But if you stop and think that all diskless clients 'mount' a swap _file_
>from the server, it makes some sense that it should work.
The quotes around "mount" are significant. There's no direct connection
between the fact that mounting a file accessed over NFS atop a directory
works and that attaching a file accessed over NFS as a swap area works.
"mounting" a swap file means "getting a file handle for it and
associating it with a "swap area" entry; reads from and writes to that
swap area get turned into NFS "read" and "write" calls using that file
handle.
"mounting" something on top of a directory, if the thing being mounted
is being mounted over NFS, means "getting a file handle for that
something and flagging that something as being 'mounted on' the
directory". There's no reason why it must *ipso facto* be possible to
mount a non-directory file atop a directory; the implementation happens
to let it work, and this may even be deliberate, but I could imagine an
implementation that supported attaching files accessed over NFS as swap
areas but that got confused by an attempt to mount a file atop a
directory (it might not be a *good* implementation, but then I didn't
say it was...).
Peter da Silva
> BTW, I agree with you that threads need not duplicate the stack.
> It doesn't seem to make much sense what happens when a thread
> returns/exits. However, I would rather see the kernel/library
> push the address of thread_exit on the stack. Eliminates one argument.
What if you want to do more stuff in your cleanup routine? This routine
would also be called if the thread called exit().
Actually, I'd like to be able to pass more stuff to thread(), such as maybe
a mask of resources to be shared...?
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Steve Lamont
>In article <46...@alvin.mcnc.org> s...@mcnc.org.UUCP (Steve Lamont) writes:
>>As quoted from <4...@ladcgw.ladc.bull.com> by fr...@ladc.bull.com (Frank Mayhar):
>>| that won't support virtual memory. Hell, by the time Gnu is ready, non-VM
>>| machines will probably be a thing of the past anyway. Shared libraries
>>Like the Cray Y-MP or Cray 3? [...]
>Actually, IMHO, a Cray is a very poor choice of hardware to run a general-
>purpose OS on. As I see it, you would want the Cray to run a minimal kernel
Why? Just because it is very fast? Sounds good to me! You don't give
any arguments to support your contention, so that gives me the privilege
of setting up a straw-person argument for the express purpose of knocking
it over (I love arguing with myself... I usually get to win! :-) ).
A common criticism heard (and one that I made until I began working on
interactive Crays some three years ago) is that you don't want to be running
vi or emacs on a Cray. The character level interrupts will kill the
poor thing. This is simply not true. They simply do not happen
frequently enough (from the machine's perspective) to worry about. If
scheduling is done correctly (that is, you schedule memory instead of
cpus) then the editor tasks are frequently tucked away in some unused crack
in memory that would be idle anyhow. If priorities are adjusted
correctly, then the task will stay in memory for quite a while before it
gets bumped out. Meanwhile, your favorite bomb code is happily
simulating the end of the universe unperturbed.
>(primarily consisting of a scheduler) that accepts compute-bound jobs from
>a client machine running some general OS, and executes them. Basically,
>a high-speed backend that runs those cpu bound jobs that are so hard on
>general-purpose OS's, and that's *all* it does. The general-purpose OS
>(running on a virtual memory machine :-) performs task scheduling, memory
>allocation, job queueing, etc, and hands the jobs to the Cray.
This is a batch processor model which will work in a number of cases,
for FORTRAN finite element weenies simulating the melt down of the local
nuke plant, or any other long running job, f'rinstance. However, there
are also a number of situations where the user wishes to interact with
the computation. In a batch mode, you really can't do that. I suppose
that a really smart compiler and operating system could divide up the
task into interactive and computationally intensive subtasks, running
the compute-bound task on the supercomputer but that's a non-trivial
thing to do and, to my knowledge, a continuing topic of research.
Perhaps you could migrate tasks from one CPU to another as their
resource utilization profile changed. I don't know. All I do know is
that there are a number of fairly successful interactive tools in common
usage on Crays and TCP/IP coupled Cray and workstation systems.
Interactivity is a must!
Consider, if you will, the task of debugging. In a batch mode, the
cycle is:
Submit job
Wait for results
Edit source file to add PRINTs or fprintf()s.
Resubmit
Wait
Edit...
Etc, etc, etc.
I know, because that's how I debugged on a batch Cray before I began
working on an interactive Cray. A tool such as adb or dbx or whatever
your favorite debugger might be tightens the cycle considerably on a
supercomputer in just the same manner as it does on a workstation or a
minicomputer.
>Disclaimer: I have no direct knowledge of how Crays work. When I made my
>comment, it was in reference to general-purpose operating systems. And, no,
>I don't think that a Cray has any business running a Real Operating System.
>(Half :-)
Since you half smiley that one, I'll give you a half serious rebuttal
:-). A Cray, or, again, any other supercomputer, should not be thought
of as simply a compute server. It is, indeed, a general purpose system
which, when the operating system is properly tuned, provides
considerable interactivity. Crays are Real (actually Double Precision)
computers which need Real Operating Systems (do I have to include the
silly LUSENET (TM) here? :-) )
If you still have doubts about this, I think I know where I can find you
a Model 029 card punch, if your really need one for your next Cray run.
( Full :-) with oak leaf clusters ).
Dick Dunn
interested in security because that's somehow at odds with free software.
I haven't quite been able to make the connection. Is there some other part
of the FSF philosophy (or RMS' personal philosophy, or whatever) that says
that security is a Bad Thing? For example:
> | }Security: ACLs? Get rid of root? Security monitors? Auditing?
> | } Provably secure(A1)?
. . .
> ...provably secure? From RMS??? You dream...
Does this imply that security is not a concern, or only "provable" security
at some level? Seems to me that if you're after some level of security,
being able to prove it is closely related (albeit not equivalent) to
knowing what you're doing.
>...(On the other hand, the lack
> of security that RMS prefers would be the biggest stumbling block in getting
> people to *use* GNU...
This is what really makes me wonder--*does* RMS really prefer a lack of
security, or are we/you/they putting words in his mouth? I just can't make
the leap. For example, I think I can like the idea of free software a
whole bunch without wanting someone else to be able to read my private
correspondence at will. Just because I trust me with my machine doesn't
mean I trust everyone in the world who owns a terminal and a modem.
--
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
...CAUTION: I get mean when my blood-capsaicin level gets low.
Leslie Mikesell
>> Besides the obvious intent of the name, there is the advantage for
>> database usage that some directory operations are atomic. That is,
>> you will normally never be able to access a filename in an inconsistent
>> state. You cannot say the same for the contents of the files unless
>> explicit locking is done.
>I've been thinking about this statement, but it still does not make any sense.
>If you do a read or write that does not span block boundaries it should be
>atomic. So a binary read or write that's a power of two bytes in length should
>have no problem. Certainly I don't think I've ever seen a problem with utmp.
I was thinking in terms of the standard unix tools which typically create
a new file or truncate an existing one and write new contents. Thus a certain
part of the time the name exists but the content is not completed even with
only one writing process -- you don't even want to think about multiple
writers with the standard tools. The only reasonable approach is to either
use a daemon process to schedule all writing or roll your own locking
procedure. Under SysV you can make /etc/link executable by everyone (or
write the corresponding program yourself) and have something that is
an atomic operation to work from in shell scripts. The more obvious
choice "ln" actually deletes the target before attempting the link(!).
BTW, what would a "power of two" bytes have to do with anything? If
your write()s happen to be alligned within blocks you might not get
the final output mixed up, but there is still no guarantee that a
reader who may be reading the whole file will see what any (even a
single) writer thinks it is putting there. That is, the reader may
read faster than the writer writes.
Les Mikesell
John F. Haugh II
> I take care of five computers running three operating systems and
>only one is UNIX (this one :-). It would be a big help to me if client
>departments could take care of the routine stuff, provided they had no
>way to add privileged users, i.e. nobody added to certain groups like
>staff, wheel, operator, and nobody added with certain uid numbers.
This can be done. The facilities are all present. All that is needed
is for a systems programmer to write a SUID root program which checks
for group membership in some admin group.
You wouldn't happen to know where we could find a systems programmer? ;-)
John F. Haugh II
>A common criticism heard (and one that I made until I began working on
>interactive Crays some three years ago) is that you don't want to be running
>vi or emacs on a Cray. The character level interrupts will kill the
>poor thing. This is simply not true. They simply do not happen
>frequently enough (from the machine's perspective) to worry about.
I have also heard that the overhead of sending single character I/O
requests over the hyperchannel was extremely costly. The discussion
I've read claims that the amount of effort handling single character
at a time I/O [ like with Vi ] is too expensive in terms of CPU
cycles.
There is a posting in one of the sources groups which provides a Vi
frontend to ed running on a Cray. I think it had a better description
of why Vi is a big loser on a supercomputer.
I was also going to disagree with Steve's remark vis memory
scheduling by pointing out that the machine has several hundred
megawords of physical memory. I think that if you found the ratio
between computes [ in MIPS or MFLOPS ] and physical memory, you
might discover that compared to a 386PC with 8MB, a Cray is lacking
memory. What do you think?
Kristoffer Eriksson
>(My scheme actually provides, as a special case, a way to obtain local
>top-level handles, but there is no inherent global hierarchy.)
Aren't you going to tell us what your scheme is? This is the second time
you mention it, without any specific details.
--
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60 ! e-mail: s...@pkmab.se
Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
Andrew Hume
I did not mean to imply that barnett is lazy;
nor that any attempt to use part of the filename for
semantic reasons is stupid (.c and .h is useful!).
my point is that if you have structured names like
<machine><report>-<option>.<time_period> (barnett's example),
the "lazy part" is putting that in the filename and using the
shell's pattern matching to select files. The alternative
(there are obviously bunches) is to put this database in a file
that looks like
<datafile>\t<machine>\t<report>\t<option>\t<time_period>
and use awk (or cut) to select on arbitrary fields. e.g.
more `awk '$2=="mymachine"{print $1}'`
this is only slighlty more work, much more flexible AND
doesn't require the kernel to support gargantuan filenames.
Barry Shein
From: gw...@smoke.BRL.MIL (Doug Gwyn)
>I think there are three classes of enhancement "wish list" items
>that people have been suggesting:
>
> - blue-sky research projects
> - significant known developments that would be a shame to
> pass up, if one is going to build an OS from scratch anyway
> - minor glitches in historical UNIX that could easily be fixed
I would add a fourth category:
- "some feature from ``my'' favorite operating system for no
obvious reason other than ``I'' am accustomed to it".
like case insensitive file options or various privilege schemes that
never worked very well in the (ahem) other OS anyhow.
My advice to these suggestions are to punt them into the trashcan*
where they belong.
--------------------
* Throwing things in a trashcan may be a concept protected by Apple,
Inc. Any similarity to real trashcans, living or dead, is purely
coincidental.
Mike Taylor
> I think [a previous poster] meant getting rid of UID == 0 being a
> privileged user. Again, this an Orange Book requirement. It also
> makes much sense. Programs should have privilege, not users. The
> ability to access a program can then be limited to a collection of
> users or groups.
Uuuh, are you sure? There seems to be a prevailing feeling that the
whole of UNIX is something that was cobbled together ar random by
people writing bits without thinking about whether or not they were
secure, made sense or whatever. While this is largely true of
Berkeley UNIX, or at least, of those bits that have been added since
V7, the concept of a root id belongs to fundamental core UNIX, it is
one of the concepts that Thompson, Richie and friends though long and
hard about when they were designing UNIX.
Granted, at that time, it was never intended primarily to be a
*secure* system, but it was *very* carefully designed, nothing was in
that hadn't been thought through, and root is no exception. Like
GOTO, I maintain that the problem with root is not that it is a flawed
copncept, but that is is misused, overused, and general ABused by
people who should know better.
The UNIX way of handling privilege IS fundamentally secure, and it's
pretty elegant to boot. You have exactly one privileged user, and one
way of inheriting that privilege -- the setuid mechanism. The fact
that many UNIX installations are insecure is due to the mess that
people have buult on top of that idea, not on the idea itself. Most
UNIXes have many things setuid to root which really dont need to be.
For example ...
> Or use /etc/group to allow some group of users to newgrp to an
> administrative account. The group ``dumpers'' might exist for persons
> taking file system dumps. All of the dumpable devices would then have
> file group ``dumpers''. Root wouldn't have to be used for dumps any
> longer.
You can already do this -- the mechanisms are in place and have been
since way way back. All that needs to be done is make the program
group-executable, and maybe setuid to whatever account it needs to be
able to access the dump device. There's almost always already a way
to do it, I have found. Whatever "it" is.
I believe in having as many accounts as necessary to run all the
standard daemons, servers &c., under their own account, so as to
decentralise privilege. Many services are setuid root in order to do
some simple thing, whereas all they really need is to be setuid to a
special account that owns whatever files need privileged access. Then
people penetrating security in, say, fingerd (not topical any more,.
but never mind) would then have obtained access to the account
"finger", but not to root. Big deal. And remember -- all this can be
done, without bending over backwards, with UNIX machinery that already
exists.
"Those who do not understand UNIX are condemned
to re-invent it, poorly" -- Henry Spencer.
______________________________________________________________________________
Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mi...@uk.ac.warwick.cs
Unkle Mirk sez: "You fritter and waste the hours in an offhand waistcoat."
John Hall
|In article <3...@amc-gw.UUCP> jh...@amc-gw.UUCP (John Hall) writes:
|>
|>Device driver interfaces, distributed files, and resources all could
|>be implemented as servers, and each server could handle it's own security,
|>resource allocation, etc. dynamically. Also, you could have servers
|>do wildcard parsing. Think of all the traverse(), parse_path(),
|>search_file(), routines that would obsolete.
|
| a typical problem with server based implementations is the additional
| layer of software that slows down the overall performance. A typical example
| is the comparison of performance between kernel based windowing systems like
| SUN view and server based systems like Xwindows.
I would be willing to take a performance hit in namei(), if this idea
was well implemented. Think of the incredible functionality it would
provide! In any case, namei() is used only when opening "files" and
slightly lower performance here would not affect system performance
much at all.
Brent Callaghan
> I would like to see a way to NFS mount or remotely link a specific file without
> having to mount a whole directory.
There's nothing in the NFS protocol or in the MOUNT protocol
that prevents you from doing this now. The only work that
needs to be done is to hack a mount daemon on the server
that'll happily hand over a file handle for a regular file.
There may, however, be assumptions (bugs) in the kernel
that may get in your way.
Made in New Zealand --> Brent Callaghan @ Sun Microsystems
uucp: sun!bcallaghan
phone: (415) 336 1051