news@sun.Eng.Sun.COM (news) (05/24/89)
What kinds of things should be in the GNU Kernel? 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.
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/24/89)
In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >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@thor.acc.stolaf.edu (Mike Haertel) (05/25/89)
In article <10317@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >>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. 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 <mike@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@ladc.bull.com (Frank Mayhar) (05/25/89)
In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: }What kinds of things should be in the GNU Kernel? 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 (frank@ladc.bull.com) Bull HN Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
news@sun.Eng.Sun.COM (news) (05/25/89)
In article <10317@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >>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 (gnu@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 bitbug@lonewolf.sun.com --------------------------------------------
madd@bu-cs.BU.EDU (Jim Frost) (05/25/89)
In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: |What kinds of things should be in the GNU Kernel? 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 madd@bu-it.bu.edu
bzs@bu-cs.BU.EDU (Barry Shein) (05/25/89)
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
vohra@uts.amdahl.com (Pavan Vohra) (05/25/89)
For what good this will do -- In article <2273@thor.acc.stolaf.edu> mike@stolaf.edu writes: >In article <10317@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>In article <106326@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 <mike@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 ---
hubcap@hubcap.clemson.edu (Mike Marshall) (05/25/89)
> > 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 hubcap@hubcap.clemson.edu
faulkner@jmullins.harvard.edu (Don Faulkner) (05/25/89)
In article <4eR602lw2cCj01@amdahl.uts.amdahl.com> vohra@uts.amdahl.com (Pavan Vohra) writes:
...
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%jmullins@harvard.harvard.edu
BITNET: faulkner@harvard
Telephone: (617) 732-2297boomer@athena.mit.edu (Don Alvarez) (05/25/89)
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 |
| boomer@SPACE.MIT.EDU Moving Soon: Princeton University Gravity Lab 8/89 |
+ -------------------------------------------------------------------------- +les@chinet.chi.il.us (Leslie Mikesell) (05/25/89)
In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >What kinds of things should be in the GNU Kernel? >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
thor@stout.ucar.edu (Rich Neitzel) (05/26/89)
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. -------------------------------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/26/89)
In article <106584@sun.Eng.Sun.COM> bitbug@lonewolf.sun.com (James Buster) writes: >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.
schwartz@shire.cs.psu.edu (Scott Schwartz) (05/26/89)
One thing to think about including is the unix++ stuff that Felix Lee 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 <schwartz@shire.cs.psu.edu>
peter@ficc.uu.net (Peter da Silva) (05/26/89)
In article <106326@sun.Eng.Sun.COM>, news@sun.Eng.Sun.COM (news) writes: > 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, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jas@ernie.Berkeley.EDU (Jim Shankland) (05/26/89)
In article <10317@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <106326@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.... 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 jas@ernie.berkeley.edu "Blame it on the lies that killed us, blame it on the truth that ran us down"
avr@mtgzx.att.com (a.v.reed) (05/26/89)
In article <106584@sun.Eng.Sun.COM>, news@sun.Eng.Sun.COM (news) writes: > In article <10317@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) 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 >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? Adam_V_Reed@att.com
decot@hpisod2.HP.COM (Dave Decot) (05/26/89)
> > 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. No, this ioctl() reassigns the associatd process group of a terminal device. It does not change the controlling terminal of any process. Dave
decot@hpisod2.HP.COM (Dave Decot) (05/26/89)
> > 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. 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@arc.UUCP (Steve Savitzky) (05/26/89)
In article <4315@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <106326@sun.Eng.Sun.COM>, news@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 >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 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!"
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/26/89)
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.
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 <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Career change search is on -- ask me for my resumefriedl@vsi.COM (Stephen J. Friedl) (05/26/89)
In article <106326@sun.Eng.Sun.COM>, news@sun.Eng.Sun.COM (news) writes: > What kinds of things should be in the GNU Kernel? > > Security: Provably secure(A1)? 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 / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "Embrace your dealer: hugs *and* drugs" - me
bitbug@lonewolf.sun.com (James Buster) (05/26/89)
In article <10322@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <106584@sun.Eng.Sun.COM> bitbug@lonewolf.sun.com (James Buster) writes: >>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. 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 bitbug@lonewolf.sun.com -------------------------------------------- -- -------------------------------------------- James Buster Mad Hacker Extraordinaire bitbug@lonewolf.sun.com --------------------------------------------
johnb@aconcagua (John R. Bashinski) (05/26/89)
In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >What kinds of things should be in the GNU Kernel? >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 johnb@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@ficc.uu.net (Peter da Silva) (05/26/89)
In article <338@arc.UUCP>, steve@arc.UUCP (Steve Savitzky) writes: > In article <4315@ficc.uu.net> peter@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. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
gsf@ulysses.homer.nj.att.com (Glenn Fowler[drew]) (05/26/89)
In article <7439@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: > 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: gsf@ulysses.att.com
hubcap@hubcap.clemson.edu (Mike Marshall) (05/26/89)
* * * 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
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (05/26/89)
In article <338@arc.UUCP>, steve@arc (Steve Savitzky) writes: >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 <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP
tvf@cci632.UUCP (Tom Frauenhofer) (05/27/89)
In article <422@ladcgw.ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes: >In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >}What kinds of things should be in the GNU Kernel? >Oh boy! Now you've asked for it! :-) "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
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/27/89)
In article <7439@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >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..
les@chinet.chi.il.us (Leslie Mikesell) (05/27/89)
In article <4613@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: [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
woods@eci386.uucp (Greg Woods) (05/27/89)
In article <7439@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: > 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. > [....] > 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@ficc.uu.net (Peter da Silva) (05/27/89)
In article <7439@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: > How about reserving a leading ^ to mean root and temporarily accepting > 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, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (05/27/89)
In article <1049@snjsn1.SJ.ATE.SLB.COM>, johnb@aconcagua (John R. Bashinski) writes: > 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. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
les@chinet.chi.il.us (Leslie Mikesell) (05/27/89)
In article <31756@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >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@alice.UUCP (Andrew Hume) (05/27/89)
In article <459@crdgw1.crd.ge.com>, barnett@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.
pekka@paix.ikp.liu.se (Pekka Akselin [The Mad Midnight Hacker]) (05/27/89)
In article <338@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes: ]In article <4315@ficc.uu.net> peter@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) ------------------------------------------------------------------------------- pekka@paix.ikp.liu.se Pekka Akselin, Sweden +46 13 172919
grr@cbmvax.UUCP (George Robbins) (05/27/89)
*Any* "Unix Compatible" OS that boots and runs!!! Let's don't confuse the
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!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)dave@mobile.UUCP (David C. Rein) (05/27/89)
In article <1049@snjsn1.SJ.ATE.SLB.COM>, johnb@aconcagua (John R. Bashinski) writes: > In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: > >What kinds of features or design rationale should it use? > [..stuff deleted..] > 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. [..stuff deleted..] > 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? > [..more stuff deleted] 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@ladc.bull.com (Frank Mayhar) (05/28/89)
In article <28855@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes: >In article <422@ladcgw.ladc.bull.com> I write: >>In article <106326@sun.Eng.Sun.COM> bitbug (James Buster) writes: >>}What kinds of things should be in the GNU Kernel? >>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? 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 (frank@ladc.bull.com) Bull HN Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/28/89)
In article <8565@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >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.
bzs@bu-cs.BU.EDU (Barry Shein) (05/28/89)
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
davecb@yunexus.UUCP (David Collier-Brown) (05/29/89)
In article <106326@sun.Eng.Sun.COM>, news@sun.Eng.Sun.COM (news) writes: | What kinds of things should be in the GNU Kernel? | Security: Provably secure(A1)? In article <1123@vsi.COM> friedl@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
jmm@ecijmm.UUCP (John Macdonald) (05/29/89)
In article <10336@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >... > >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
dsmythe@cup.portal.com (dave l smythe) (05/29/89)
I would epect that RMS would have little interest in security (at best
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-timesmartin@iemsun.dhc (Stephen Martin) (05/29/89)
I would like to see a way to NFS mount or remotely link a specific file without
having to mount a whole directory.
--
___ ___ ___ ___ _ _ ___
/__/ / / /__ / /\ / / _ Stephen Martin, Boeing Canada, Toronto.
/__/ /__/ /__ _/_ / / /__/
Nuke the Raisins
UUCP: smartin@iemisi.UUCP
{uunet|suncan}!jtsv16!marsal1!iemisi!smartinjay@silence.princeton.nj.us (Jay Plett) (05/29/89)
In article <9402@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes: - In article <459@crdgw1.crd.ge.com>, barnett@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. jay@princeton.edu
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (05/30/89)
In article <11666@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: > 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: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (05/30/89)
In article <4315@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <106326@sun.Eng.Sun.COM>, news@sun.Eng.Sun.COM (news) writes: >> Security: ACLs? > >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. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
madd@bu-cs.BU.EDU (Jim Frost) (05/30/89)
In article <8565@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |In article <31756@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: |>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? 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 madd@bu-it.bu.edu
madd@bu-cs.BU.EDU (Jim Frost) (05/30/89)
In article <280@ecijmm.UUCP> jmm@ecijmm.UUCP (John Macdonald) writes: |In article <10336@smoke.BRL.MIL> gwyn@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 |system capabilities [...] |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. jim frost software tool & die madd@bu-it.bu.edu
david@indetech.UUCP (David Kuder) (05/30/89)
In article <11666@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: >A few observations on security... And in article <1123@vsi.COM> friedl@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.
ka@june.cs.washington.edu (Kenneth Almquist) (05/30/89)
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.
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 Almquistpeter@ficc.uu.net (Peter da Silva) (05/30/89)
In article <10332@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > 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, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (05/30/89)
In article <31965@bu-cs.BU.EDU>, madd@bu-cs.BU.EDU (Jim Frost) writes: > 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. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
sjs@spectral.ctt.bellcore.com (Stan Switzer) (05/30/89)
In article <8380@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: > 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 sjs@ctt.bellcore.com
les@chinet.chi.il.us (Leslie Mikesell) (05/30/89)
In article <9402@alice.UUCP> andrew@alice.UUCP (Andrew Hume) 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. 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@plx.UUCP (Evan Bigall) (05/30/89)
In article <157@paix.ikp.liu.se> pekka@paix.ikp.liu.se (Pekka Akselin [The Mad Midnight Hacker]) writes: >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@mpx2.mpx.com (Erik Murrey) (05/30/89)
In article <28855@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes: >In article <422@ladcgw.ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes: >>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. / | / / /____/ |/ erik@mpx.com / / / / /| Data Systems, Inc. {vu-vlsi, bpa, cbmvax}!mpx1!erik / / / / |====================
rbj@dsys.icst.nbs.gov (Root Boy Jim) (05/31/89)
? From: Doug Gwyn <gwyn@smoke.brl.mil> ? 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?
rbj@dsys.icst.nbs.gov (Root Boy Jim) (05/31/89)
? From: Leslie Mikesell <les@chinet.chi.il.us> ? 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 Root Boy Jim is what I am Are you what you are or what?
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (05/31/89)
In article <9402@alice.UUCP>, andrew@alice (Andrew Hume) writes: >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 <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!crdgw1.ge.com!barnett barnett@crdgw1.UUCP
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (05/31/89)
In article <4347@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >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. 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. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
sys1@antares.mcs.anl.gov (Systems Programmer) (05/31/89)
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%niuvax.UUCP@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 *
**********************************************************************les@chinet.chi.il.us (Leslie Mikesell) (05/31/89)
In article <10336@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >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
les@chinet.chi.il.us (Leslie Mikesell) (05/31/89)
In article <19808@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: >? 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.
aglew@xenurus.gould.com (05/31/89)
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 clockpeter@ficc.uu.net (Peter da Silva) (05/31/89)
In article <8587@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > 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). -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
gil@banyan.UUCP (Gil Pilz@Eng@Banyan) (05/31/89)
In article <8380@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >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. 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. gil@banyan.com Banyan Systems Inc. (617) 898-1196 115 Flanders Road Westboro, MA 01581 -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
peter@ficc.uu.net (Peter da Silva) (06/01/89)
In article <16603@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > In article <4347@ficc.uu.net> peter@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. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jhall@amc-gw.UUCP (John Hall) (06/01/89)
One thing I would like to see would be a formalized set of hooks into the 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..." |
allbery@ncoast.ORG (Brandon S. Allbery) (06/01/89)
As quoted from <422@ladcgw.ladc.bull.com> by frank@ladc.bull.com (Frank Mayhar): +--------------- | In article <106326@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 allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@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
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/01/89)
In article <4346@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >AmigaDOS doesn't have a namesystem root. It's annoying... 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.)
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/01/89)
In article <438@banyan.UUCP> gil@banyan.com writes: >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.
bzs@bu-cs.BU.EDU (Barry Shein) (06/01/89)
From: les@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
spl@mcnc.org (Steve Lamont) (06/01/89)
In article <13688@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
<As quoted from <422@ladcgw.ladc.bull.com> by frank@ladc.bull.com (Frank Mayhar):
<+---------------
<| }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
<+---------------
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: spl@ncsc.org
North Carolina Supercomputing Center Phone: (919) 248-1120
Box 12732/RTP, NC 27709jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/01/89)
In article <4357@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >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). 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. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
ashok@stiatl.UUCP (Ashok Yerneni) (06/01/89)
In article <395@amc-gw.UUCP> jhall@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. > > 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
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (06/01/89)
? From: Peter da Silva <peter@ficc.uu.net> ? 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, peter@ficc.uu.net, +1 713 274 5180. ? Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. Root Boy Jim is what I am Are you what you are or what?
peter@ficc.uu.net (Peter da Silva) (06/01/89)
In article <16607@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > 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. 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, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
usenet@cps3xx.UUCP (Usenet file owner) (06/02/89)
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 | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
frank@ladc.bull.com (Frank Mayhar) (06/02/89)
In article <4609@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: >As quoted from <422@ladcgw.ladc.bull.com> by frank@ladc.bull.com (Frank Mayhar): >| 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? [...] 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 (frank@ladc.bull.com) Bull HN Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241
peter@ficc.uu.net (Peter da Silva) (06/02/89)
In article <19835@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: > 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, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
spl@mcnc.org (Steve Lamont) (06/02/89)
In article <424@ladcgw.ladc.bull.com> frank@ladc.bull.com (Frank Mayhar) writes: >In article <4609@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: >>As quoted from <422@ladcgw.ladc.bull.com> by frank@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 >>Like the Cray Y-MP or Cray 3? [...] > [deletion] >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 ). -- spl Steve Lamont, sciViGuy EMail: spl@ncsc.org North Carolina Supercomputing Center Phone: (919) 248-1120 Box 12732/RTP, NC 27709
les@chinet.chi.il.us (Leslie Mikesell) (06/02/89)
In article <4357@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> 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
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (06/02/89)
In article <19812@adm.BRL.MIL> niuvax!sys1@antares.mcs.anl.gov (Systems Programmer) writes: > 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 +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : <backbone>!bigtex!rpp386!jfh +--------------------------------------
ske@pkmab.se (Kristoffer Eriksson) (06/02/89)
In article <10343@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >(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: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
andrew@alice.UUCP (Andrew Hume) (06/02/89)
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.bzs@bu-cs.BU.EDU (Barry Shein) (06/02/89)
From: gwyn@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. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
jhall@amc-gw.UUCP (John Hall) (06/03/89)
In article <5021@stiatl.UUCP> ashok@stiatl.UUCP (Ashok Yerneni) writes: |In article <395@amc-gw.UUCP> jhall@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. |Ashok Yerneni gatech!stiatl!ashok |Sales Technologies, Inc |3399 Peachtree Rd, NE |Atlanta, GA | off (404) 842-9319 | res (404) 634-4398 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..." | -- 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..." |
brent%terra@Sun.COM (Brent Callaghan) (06/03/89)
In article <SMARTIN.89May29072600@iemsun.dhc>, smartin@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. 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
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/03/89)
In article <1232@pkmab.se> ske@pkmab.UUCP (Kristoffer Eriksson) writes: >Aren't you going to tell us what your scheme is? I'd rather not, at least not until the research types have finished working it over, but the basic notion is "it takes a handle to get a handle". If that doesn't help, sorry -- wait until later when I have time to write it up (assuming it still seems like a good notion then).
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (06/03/89)
? From: Peter da Silva <peter@ficc.uu.net>
? In article <19835@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes:
? > 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().
Then have your thread do it explicitly, just like main does. Or if you
insist, have thread_exit honor exit callbacks, similar to how on_exit
does. Better yet, push the address of thread_die_horribly() on the stack
and require that the thread exits explicitly. Require that main() exit
explicitly by hacking startup to dump core on return from main.
? Actually, I'd like to be able to pass more stuff to thread(), such as maybe
? a mask of resources to be shared...?
Share everything that fork does. Close/release what you don't want.
? Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
? Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
? Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
Root Boy Jim is what I am
Are you what you are or what?bvs@light.uucp (Bakul Shah) (06/03/89)
In article <10357@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <1232@pkmab.se> ske@pkmab.UUCP (Kristoffer Eriksson) writes: >>Aren't you going to tell us what your scheme is? > >I'd rather not, at least not until the research types have finished >working it over, but the basic notion is "it takes a handle to get a >handle". If that doesn't help, sorry -- wait until later when I have >time to write it up (assuming it still seems like a good notion then). Seems like you are advocating giving explicit handles for things like root, current dir. to a user process instead of the current `hidden' handles (which exist in the u. struct and are managed by the kernel). So then calls like open("/etc/passwd", ...) and open("src/os", ...) can be replaced by calls like obj_open(root, "etc/passwd", ...) and obj_open(cwd, "src/os", ...) In effect the concept of `current directory' disappears as one can keep any number of directory handles around and walk relative to them. Which directories can be walked depends upon the initial set of handles + directories reachable from this initial set. We can generalize this behavior by replacing all Unix system calls that depend on objects managed by the kernel on behalf of the user with system calls that require explicit handles and let the user handle them himself. If this is sort of what you have in mind, I like it. I'd go one step further and throw away the current flat system- call interface. Instead I'd define what kinds of objects are implemented by a Unix like OS and define a minimum set of operations for each kind. Then every system call is a request for a specific operation, made on an object whose handle is held by the user process. A compatibility library can be built to allow running of standard Unix programs atop this object oriented Unix. -- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>
peter@ficc.uu.net (Peter da Silva) (06/03/89)
In article <32171@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > - "some feature from ``my'' favorite operating system for no > obvious reason other than ``I'' am accustomed to it". > like case insensitive file options... Sorry. My favorite operating system is UNIX. And I still think case- insensitive file names are handy. However they'll never work for UNIX. Why? They'll never fly in Japan. Same with any sort of fancy new command option scheme. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
snoopy@sopwith.UUCP (Snoopy) (06/05/89)
In article <11666@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: | 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). A simple cron job could do the software portion of this right now. If you want the tape ejected under software control, talk to the people that design tape drives. (And to the people that design the removable media optical r/w drives. If the disks for the NeXT drives cost $50/256MB, they are cheaper per MB than the QIC tapes I'm currently using.) _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *am* the next man!" -Indy
snoopy@sopwith.UUCP (Snoopy) (06/05/89)
In article <338@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes: |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. UTek's DFS also uses the leading // syntax. I like the idea of the network being a "superroot" very much. It's a very nice way of thinking about it. The namespace is orthogonal, all machines appear at the same level. The conventional absolute pathname can be thought of as a relative pathname beginning at the local machine. Rob Pike and others have advanced arguments that this sort of thing is abuse of the syntax. These arguments shouldn't be taken lightly. In practice, the // syntax works very well, I have run into 0 problems in 4.5 years of using it. What we *really* need to avoid is a requirement of mounting filesystems from remote machines in order to access them. It should be possible to develop a system using, say the /n/host/ syntax that doesn't require mounting filesystems all over creation. Being able to select stateful or stateless behaviour on a per file descriptor basis ( flag in the open() call? ioctl()? ) would be nice. Whatever syntax is chosen, it should be possible for an unprivileged user to do the equivalent of: ln -s //somehost/usr/foo/bar bar The abilities to allow remote access on a per-account basis, and to translate hostA,user1 into localhost,user2 on a per-host, per-user basis are also important. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *am* the next man!" -Indy
snoopy@sopwith.UUCP (Snoopy) (06/05/89)
In article <1989May26.224924.5293@eci386.uucp> woods@eci386.UUCP (Greg Woods) writes: | Second, a leading '//' with a special meaning is a tremendous KLUDGE! | It's even worse than "machine_A:/"! Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge. Your syntax attaches special to another character. With the // syntax, the special chars remain limited to / and null. |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. Why do you want to have to mount somebody else's filesystem on your system just to be able to access it? It's already mounted on their system. All you need is a way to get to it. One additional requirement I forgot to list in my previous article is that remote devices must be as transparent as regular files. Some inferior network filesystems break the "a file is a file is a file" rule. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *am* the next man!" -Indy
snoopy@sopwith.UUCP (Snoopy) (06/05/89)
In article <157@paix.ikp.liu.se> pekka@paix.ikp.liu.se (Pekka Akselin [The Mad Midnight Hacker]) writes: |]In article <4315@ficc.uu.net> peter@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. .. |Why don't make the filename length dynamic!? There appears to be some misunderstanding about the BSD fast filesystem. The length of the filename *is* dynamic, with an upper limit of 255. The system does not waste 254 bytes to store a one character filename. In fact, a one char filename would use *less* space in the new filesystem than in the old. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *am* the next man!" -Indy
snoopy@sopwith.UUCP (Snoopy) (06/05/89)
In article <19808@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes: |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. This fundamentally changes the concept of root. This would break many things. It sounds like you are looking for a way to make a directory read-only without setting up a partition to be mounted read-only. Is this correct, or did you have something else in mind? What I would like added to the conventional rwx triplets is an append permission bit. This would give permission to append to a file, but not to delete or modify existing contents. Useful for log files, mail could be delivered by an unprivileged process, etc. _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "I *am* the next man!" -Indy
Makey@LOGICON.ARPA (Jeff Makey) (06/05/89)
In article <9402@alice.UUCP> andrew@alice.UUCP (Andrew Hume) writes: >storing information is what a filesystem is for. >if you want to use regular expressions, put the information >in a file. File names are stored in directories. Directories are files. What's the problem? >don't complicate a universal mechanism like >the file-system name space just so you can be lazy about >selecting filenames. How does the kernel become more complicated just because file names can be 255 characters long instead of 14? Just change a #define'd constant and away you go. Considering that C provides poor support for character strings that may or may not be null-terminated (the format in which the short filenames are stored), the Berkeley directory format may actually result in a simpler kernel! Long file names are useful. Just because 14 characters is enough for you does not mean it is enough for anyone else. Will you next suggest that 65535 inodes are enough for *any* file system? :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/05/89)
In article <1989Jun3.004854.18111@light.uucp> bvs@light.UUCP (Bakul Shah) writes: > obj_open(cwd, "src/os", ...) >In effect the concept of `current directory' disappears ... Yup, you got it. Using a null "existing handle" argument gets a local top-level handle. If you think how this can be implemented (handle is a kernel data pointer), then consider how the kernel implementation of "pathname" parsing for obj_open (which I think of as "subopen") can take advantage of the uniformity, you'll see some of the other potential advantages. This seems to nicely accommodate portals, remote object access, and so forth.
bvs@light.uucp (Bakul Shah) (06/06/89)
In article <10364@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <1989Jun3.004854.18111@light.uucp> bvs@light.UUCP (Bakul Shah) writes: >> obj_open(cwd, "src/os", ...) >>In effect the concept of `current directory' disappears ... > >Yup, you got it. Using a null "existing handle" argument gets a local >top-level handle. If you think how this can be implemented (handle is >a kernel data pointer), then consider how the kernel implementation of >"pathname" parsing for obj_open (which I think of as "subopen") can >take advantage of the uniformity, you'll see some of the other potential >advantages. This seems to nicely accommodate portals, remote object >access, and so forth. Three comments. 1. If the return value and the first arg. to obj_open have the same type, you can do things like `cwd = obj_open(root, "etc", ...)'. This type should be same as an ordinary descriptor (an already known quantity) instead of a kernel data pointer. 2. Use of a `null "existing handle" argument' would force the kernel to maintain a special handle which does not seem like a good idea. It is equally easy (and less magical) to let each process inherit the handles it needs. You may say the kernel already maintains u_cdir (cwd) and u_rdir (root) inode ptrs so what is the big deal. My point is that we don't need them so why keep them. IMO kernel maintained variables are even worse than global variables. 3. Access to portals etc. can be very useful but obj_open (or subopen) by itself won't do it. The real key is in how it is plugged into the modules implementing portals, remote objects and such. I see obj_open as one step on the way to a *small* object kernel. Anyone working on such a thing? -- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>
guy@auspex.auspex.com (Guy Harris) (06/06/89)
>How does the kernel become more complicated just because file names >can be 255 characters long instead of 14? Just change a #define'd >constant and away you go. Assuming the extra space taken up by 258-byte (or 260-byte) directory entries - or the extra time it takes to zip through the bigger directories - isn't a problem. I guess Kirk McKusick thought they *were* a problem, and added a more complicated scheme to permit variable-length directory entries. >Considering that C provides poor support for character strings that may >or may not be null-terminated (the format in which the short filenames >are stored), the Berkeley directory format may actually result in a >simpler kernel! Well, it *didn't* result in a simpler kernel. The added complication of dealing with "null-or-size-terminated strings" is pretty minimal. I like long file names, too, but you *do* have to admit that the BSD file system's directory-handling code is more complicated, in part, due to the more complicated directory entry structure.
guy@auspex.auspex.com (Guy Harris) (06/06/89)
>What we *really* need to avoid is a requirement of mounting filesystems >from remote machines in order to access them. It should be possible to >develop a system using, say the /n/host/ syntax that doesn't require >mounting filesystems all over creation. Well, if you want to avoid the requirement that *you* (or your system administrator) have to type a "mount" command in order to access a file system, the ONC/NFS "automounter" has, at least in my experience, done a decent job of this; it's a user-level NFS server that can be mounted onto one or more directories, and that implements a funny namespace in those directories such that references to names in those directories cause remote file systems to be mounted over NFS; the name is then claimed to be a symlink to the appropriate directory (or file?) within that file system.
rang@cpsin3.cps.msu.edu (Anton Rang) (06/06/89)
[ various notes about distributed file systems removed ] Just out of curiousity, is anyone out there using the Andrew system (AFS)? I've been told that the machines hooked up to it have a truly transparent file system (i.e. a friend of mine at Univ. of Mich. can get at files on CMU's systems without knowing which campus they're on). True? If so, I'd think this would be much preferable to all the "remote mount" junk.... For security...something along the lines of Kerberos would be great. +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
woods@eci386.uucp (Greg A. Woods) (06/06/89)
In article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > In article <1989May26.224924.5293@eci386.uucp> woods@eci386.UUCP (That's ME) writes: > > | Second, a leading '//' with a special meaning is a tremendous KLUDGE! > | It's even worse than "machine_A:/"! > > Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge. > Your syntax attaches special to another character. With the // syntax, > the special chars remain limited to / and null. I see '//' as a huge kludge, 'cause it special-cases the meaning of two consecutive slashes when they appear at the beginning of a line. This goes directly against the understood meaning of consecutive slashes (i.e. scrunch them into one slash). The "mach_A:/" at least identifies this syntax as a kludge (to the eye, and the machine). Besides, using a second character is better than overloading an already used one. Of course I don't like either syntax. I want to be able to put directory hierarchies anywhere I please, whether they are on a remote machine, or local. That's part of what network tranparency for filesystems is all about. The meaning of "mounting a filesystem" should be exactly the same, be it a local mount of a physically local disk, or a remote mount of a filesystem advertised to the network. Further in article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > Why do you want to have to mount somebody else's filesystem on your > system just to be able to access it? It's already mounted on their > system. All you need is a way to get to it. Cause if I'm on a metropolitan sized network (> 1000 machines), I don't want 1000 root directories! But that's only a tiny part of it. The way to get into some filesystem is to mount it. It doesn't matter where that filesystem physically resides. This is part of filesystem semantics. Besides, I don't want to have to make my entire filesystem available to the network. I may want to make all of some local mount (i.e. partition) available, or I may want to make an entire directory hierarchy (other than root) available, and I don't want the ability to make all of my filesystem available. One way to do this by advertising a directory name to the network as available to be mounted remotely. I may want to be able to put a password on this capability too, perhaps in conjunction with some form of authentication service like Kerberos(sp?). Even further in article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: > One additional requirement I forgot to list in my previous article > is that remote devices must be as transparent as regular files. > Some inferior network filesystems break the "a file is a file is a file" > rule. Of course. That's another aspect to transparency. RFS goes to great lengths not to break filesystem semantics (and so far as I can see, it succeeds). The entire concept of network transparency to filesystem semantics is of utmost importance. If attention is not paid to this aspect, of an operating system, the result will be another huge pile of kludges. PS: I had hoped, given the forum, that I wouldn't have to "waste" bandwidth talking about this stuff in detail. However, if one person responds in such a way to indicate I didn't get my point across, I'd guess there are at least 10 more who didn't get it either. Anyway, I don't mind stating my humble opinion! :-) No offense intended Snoopy! PPS: I should hope this discussion is not only serving to clarify a few points, but to also provide some input to those people who want to work on the GNU design and implementation. -- 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
jfc@athena.mit.edu (John F Carr) (06/06/89)
In article <3306@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: >Just out of curiousity, is anyone out there using the Andrew system >(AFS)? I've been told that the machines hooked up to it have a truly >transparent file system (i.e. a friend of mine at Univ. of Mich. can >get at files on CMU's systems without knowing which campus they're >on). True? If so, I'd think this would be much preferable to all the >"remote mount" junk.... > For security...something along the lines of Kerberos would be great. We use AFS+Kerberos at project Athena. It's now in the almost releasable state. There are some changes that need to be made before we can use it for normal file service. It should be said that AFS is not a replacement for NFS. Ways in which AFS wins: Performance: it keeps a local cache of recently accessed files (this cache is not destroyed by reboot), so performance is much better. Transparency: there is no need to explicitly mount a filesystem. Directories can be moved around without the owner knowing or caring (important for load-balancing). I can tell anyone to look at athena.mit.edu/mit/jfc/README.afs in his afs filesystem, and he will be able to get to it from anywhere with a net connection. Quota: quota control is per-directory instead of per-filesystem (this is an important requirement in our environment, since per-user quota doesn't "do the right thing" on group-writeable directories). Access control: Access control lists per directory, updates are instantaneous. (At Athena the group lists on NFS servers are updated no more than daily.) Ways in which AFS loses: Access control: There are per-directory acls, but no way (yet) to set permission on an individual file. Filesystem format: You can't export a UNIX filesystem via AFS. There isn't any good way to get at AFS files on the same machine, except through AFS (which means sending them over the network, back to your disk [now in your AFS cache], and then reading them). Ease of setup: With our Kerberos authenticated NFS, untrusted servers are possible (since each NFS server uses a different key to authenticate requests, breaking into one server does nothing for the others). With AFS, all servers share a key (so root access to a server is equivalent to root access to files on other local servers). This means you can't add a random machine to AFS while maintaining security. Some of the problems will be fixed over time. For most of our file service needs, AFS wins big over NFS. NFS won't go away, because it is more widely used (measured by number of sites and number of machine/OS types) and because it works with a UNIX filesystem, but it will get a lot less use in the future. --John Carr (jfc@athena.mit.edu)
richard@torch.UUCP (Richard Nuttall) (06/06/89)
No one has yet mentioned the User Interface. I think that considering
the User Interface component of your system at the earliest stage
is essential. (Or do you intend just to give everyone VT100 emulators
and SHi 8-| ).
Points to consider:
1) What UI are software developers going to use on your system?
2) What low-level primitives could you provide in the OS that will
make UI development easier?
3) Do you want the machine to boot up directly into a fancy graphical
interface rather than the standard console?
4) What languages are you going to provide for the users? Will the
choice of languages have an impact on how you write the OS?
5) What graphics system are you going to provide? Is it going to
allow code to be ported to/from it?
Here are some of the answers I would like to see.
1) The system will use a widely available UI, which will be bundled
in with the system. This will consist of (e.g. X, with PEX), as a
portability layer, and a UI style on top (MOTIF? but this would
probably cost money :-) ).
Something like what the NeXT machine came with.
2) If you are going for X, then there are several low-level primitives
that would help considerably.
a) Very fast context switching, so that Server and Client can
swap quickly. (This would obviously be of great benefit
elsewhere).
b) A fast IPC mechanism, that can cope with large amounts of data
(e.g. a 1024 X 1024 X 8bits Pixmap)
3) The "average" user is not interested in the console, and wants
to have a powerfull interface immediately available on boot up
("O.K., so configure the system" I hear you say). If you always
have this interface available, the OS can use it to communicate
with the user, i.e with popup menus, message boxes, dialog
boxes, and configuration panels.
4) Presumably you will provide C (GCC ? ). How about G++ as standard.
Now you can go further. How about a fully object oriented standard
library, (with C header files for those that don't want to use C++).
File IO, for instance can be based around the FILE object and its
methods, this in turn has the low-level file IO object as a parent
in the class hierarchy.
Windows, menus, message boxes, scrollbars can all be such objects.
Again, the NeXT machine gives you some idea of what I want. But, don't
go as far as the Mac, in removing terminals, etc! I still want to
be able to type a command occasionally 8-) .
5) Using X/PEX will make things fairly portable, but, this clashes with
my wish to have everything object oriented and in C++. I don't have
an easy answer here. My preference would be to allow a C interface,
but to encourage C++ and an object oriented approach where possible.
Footnote: I know it is possible to program in an object oriented manner in C,
but it is hard work and not very pretty (Just try writing an X11 widget!!!!!).
--
Richard Nuttall | ukc!stc!datlog!torch!richard
Torch Technology Ltd. | 0223 841000 X 309
Cambridge England | edler@cmcl2.NYU.EDU (Jan Edler) (06/07/89)
In article <1989Jun3.004854.18111@light.uucp>, bvs@light.UUCP (Bakul Shah) writes: > open("/etc/passwd", ...) >and > open("src/os", ...) > >can be replaced by calls like > > obj_open(root, "etc/passwd", ...) >and > obj_open(cwd, "src/os", ...) > >In effect the concept of `current directory' disappears as one can >keep any number of directory handles around and walk relative to >them. Which directories can be walked depends upon the initial >set of handles + directories reachable from this initial set. We considered extending the kernel/user interface in something like this way, but tentatively rejected it. Our goal wasn't to "objectify" the system, or to move namei out of the kernel, or anything like that. It was simply to generalize the notion of cwd, so that a process can efficiently reference files in any of several frequently-used directories. We decided that it was better to extend the pathname notion, than to extend all system calls taking pathnames so they take a handle too. The reason for this preference wasn't to avoid modifying all those system calls, or to avoid needing a compatibility library. It was the desire to treat handle+path specifications as simple strings that can be used exactly the same way pathnames have always been used. We've been a bit indecisive about the exact form of pathname extension. My current preference is to say that "/@" at the beginning of a pathname, followed by a file descriptor number (as a string of digits) and a "/", means to take the object referred to by the file descriptor as the search starting point. There are several issues relevant to this design, including: - Prevention of real entries in "/" like "@nnn". This is aesthetically unfortunate, but I don't think it's too serious. How many systems out there have entries in / like this? - Inability to transparently splice "/" on the front of a pathname. This is easily fixed by allowing 1 or more "/" chars in front of the "@". - We have to decide what to do about paths like "/foo/../@nnn/bar" and /@rootfd/@nnn/bar: my preference is that they are undefined -- /@nnn only has special meaning at the beginning of a path. But it wouldn't be too hard to make such paths work in the "expected" way. - "Dangling reference" confusion resulting when a program closes a file descriptor and later uses a pathname dependent on that fd. Of course the serious problem is when the fd has since been reassigned by a subsequent open. There is no better fix for this problem than to insist that programmers not close descriptors they didn't open (except for 0,1,2). - The need to convert back and forth between strings and integers is annoying. - A new open flag (O_EXEC), as previously discussed in this newsgroup, might be useful when dealing with file descriptors of directories. - Changing the lead-in string from "/@nnn" to "/@/nnn" might be advantageous because /@/ could be implemented as some kind of mount point on some systems, although this would be slower than more direct implementation strategies. - We have to decide about the degenerate case, opening "/@nnn" (i.e., nothing after the fd): does the resulting file descriptor share the same file pointer as the original? This question must also be addressed by /dev/fd/nnn implementations (do they all do the same thing in every case?). I'm sure I've forgotten some additional issues. Nevertheless, the ability to express such "handles" as part of pathname strings seems valuable. We can define conventional environment strings like $cwd, $root, and others, containing the file descriptor numbers to be inherited over exec; this removes the need to define special meaning for additional fd numbers, beyond 0,1,2. Any comments? Jan Edler NYU Ultracomputer Research Laboratory edler@nyu.edu ...!cmcl2!edler (212) 998-3353
bvs@light.uucp (Bakul Shah) (06/07/89)
In article <40062@cmcl2.NYU.EDU> edler@cmcl2.UUCP (Jan Edler) writes: >In article <1989Jun3.004854.18111@light.uucp> bvs@light.UUCP (Bakul Shah) writes: >> open("/etc/passwd", ...) >>and >> open("src/os", ...) >> >>can be replaced by calls like >> >> obj_open(root, "etc/passwd", ...) >>and >> obj_open(cwd, "src/os", ...) >> > >We considered extending the kernel/user interface in something like >this way, but tentatively rejected it. [edited] >We decided that it was better to extend the pathname notion, than to >extend all system calls taking pathnames so they take a handle too. >The reason for this preference ... was the >desire to treat handle+path specifications as simple strings that can >be used exactly the same way pathnames have always been used. > ... > My current preference is to say that "/@" at the beginning >of a pathname, followed by a file descriptor number (as a string of >digits) and a "/", means to take the object referred to by the file >descriptor as the search starting point. [edited out a list of relevant issues/problems] >Any comments? 1. If the goal in introducing the ``/@nnn/foo/bar'' syntax is to efficiently reference files in any of several frequently-used directories, then the number of new problems introduced by the new notation seems like too heavy a price to pay for it. 2. I am not sure I understand the benefit of keeping handle + path spec. as simple strings. I am hoping for something stronger than ``that is how pathnames have always been used''. 3. A naming scheme like yours can be implemented on top of a simpler scheme (like obj_open) and entirely in user mode. IMHO this is a Good Thing (atleast until you iron out all the problems in your scheme :-) 4. You need not objectify all system calls. If all you want is the convinience of multiple current working directories, you can simply add a new syscall for obj_open() and replace open() syscall by open() library routine. At this point I am not too keen about any new feature that *increases* the size of a kernel. Sys V / 4.3 BSD kernels are already too big and still, they are limited. In their place I would like to see a simple kernel that I can completey understand and keep in my head without having to flush out everything else. This kernel should implement a small set of very simple mechanisms from which existing interfaces and more can be built. I believe an object kernel + a user-level shared library for compatibility can meet this goal. Now all I need is some time and resources to prove this.... -- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>
evas@euraiv1.uucp (Eelco van Asperen) (06/07/89)
A feature I liked in Bell Labs "Plan 9" was the separate name-space for each user (or process?). Such name-spaces would allow an elegant solution for networks of heterogenous computers; "/bin/sh" would always to the standard shell, no matter what machine you're working on. It would provide you with a uniform view of the file-system no matter where you are logged in. -- Eelco van Asperen Uucp: evas@cs.eur.nl || Earn/Bitnet: asperen@hroeur5 "Stick a fork in their ass and turn them over, they're done", Lou Reed, Last Great American Whale
peter@ficc.uu.net (Peter da Silva) (06/07/89)
In article <40062@cmcl2.NYU.EDU>, edler@cmcl2.NYU.EDU (Jan Edler) writes: > We've been a bit indecisive about the exact form of pathname > extension. My current preference is to say that "/@" at the beginning > of a pathname, followed by a file descriptor number (as a string of > digits) and a "/", means to take the object referred to by the file > descriptor as the search starting point. This is an intriguing idea. I, myself, would prefer to make '@' by itself at the beginning of a file name a special token. This solves the problem of files beginning with @ in /tmp... I'd generalise it beyond directories, too. That way you could open '@5' to clone a descriptor. This is similar to the /dev/fd/5 syntax described by people using more recent bell releases, except that you can't chdir to /dev/fd/5/workdir. Actually, if you have a /dev/fd/5/..., then you don't need a special syntax. The other thing this could be used for (getting back to @5 for a moment) is networks. If you're going to make @ special anyway, why not use it where // is used today in some networks. Instead of //frodo/usr/baggins use @frodo/usr/baggins. And maybe one day I could chdir to @cmcl2.NYU.EDU/usr/edler. Of course this could be implemented as /dev/net/cmcl2.NYU.EDU/usr/edler. I don't mind the syntax, I just don't care for the explicit mounting business. I'm not too thrilled with it for disks, either. I'd love to type "cd /dev/dsk/mydisk" and have it reply with "please insert volume mydisk in any drive"... Just a little namei hav`cking, eh? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (06/07/89)
? From: "Greg A. Woods" <woods@eci386.uucp> ? In article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: ? > In article <1989May26.224924.5293@eci386.uucp> woods@eci386.UUCP (That's ME) writes: ? > ? > | Second, a leading '//' with a special meaning is a tremendous KLUDGE! ? > | It's even worse than "machine_A:/"! ? > ? > Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge. ? > Your syntax attaches special to another character. With the // syntax, ? > the special chars remain limited to / and null. ? I see '//' as a huge kludge, 'cause it special-cases the meaning ? of two consecutive slashes when they appear at the beginning of a ? line. This goes directly against the understood meaning of ? consecutive slashes (i.e. scrunch them into one slash). Agreed. It is too easy to generate consecutive `/'s by accident, and I would prefer that they map to just one as they do now. ? The "mach_A:/" at least identifies this syntax as a kludge (to the ? eye, and the machine). Besides, using a second character is ? better than overloading an already used one. I also agree here, but see below. ? Of course I don't like either syntax. Nor do I. ? I want to be able to put ? directory hierarchies anywhere I please, whether they are on a ? remote machine, or local. That's part of what network tranparency ? for filesystems is all about. The meaning of "mounting a ? filesystem" should be exactly the same, be it a local mount of a ? physically local disk, or a remote mount of a filesystem ? advertised to the network. I disagree here. I feel that they should be mounted in a standard place. We use NFS here, and are considering the following scheme. Every file should be accessible via /<host>/<path>, where <path> is the pathname as it would appear on <host>. Local filesystems can be remounted on /<name_of_local_host>/<path>. The problem here is that it is not a good idea to mount fs's directly under root, so that in actuality, machine `foo's /usr is mounted on /net/foo/usr and /foo is a symbolic link to /net/foo. Another problem is symbolic links. To work everywhere, they must be relative. There are times when you might want absolute ones, however. I feel that Sun has only partially addressed this problem. They seem to have some kind of generalized scheme in which pathnames could be predicted, but it seems somewhat inverted. All the home directorys are mounted under /home/<host>, which seems a bit backwards to me. Other directorys I have seen mentioned are /export. My recollection is fuzzy on exactly what their scheme is. Comments? ? 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 Root Boy Jim is what I am Are you what you are or what?
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (06/08/89)
? From: Snoopy <snoopy@sopwith.uucp>
? In article <19808@adm.BRL.MIL> rbj@dsys.icst.nbs.gov (Root Boy Jim) writes:
? |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.
? This fundamentally changes the concept of root. This would break many things.
? It sounds like you are looking for a way to make a directory read-only without
? setting up a partition to be mounted read-only. Is this correct, or did you
? have something else in mind?
That's *exactly* what I had in mind. The default umask would leave these
bits alone, so they wouldn't get reset unless you wanted them to.
Read what I said. I want to temporarily prohibit root from modifying
parts of a RW fs. Yes, I could use a RO fs, but that's not always
convenient. Note that VMS (as did RSX) has a set of privilege bits
that apply to system accounts. They must be set (and the system or
owner can always do this) to gain access.
? _____ .-----.
? /_____\ Snoopy ./ RIP \.
? /_______\ qiclab!sopwith!snoopy | |
? |___| parsely!sopwith!snoopy | tekecs |
? |___| sun!nosun!illian!sopwith!snoopy |_________|
? "I *am* the next man!" -Indy
I like the Austrian way better.
Root Boy Jim is what I am
Are you what you are or what?cline@sun.soe.clarkson.edu (Marshall Cline) (06/08/89)
In article <19915@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: >> From: "Greg A. Woods" <woods@eci386.uucp> >> In article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: >>> In article <1989May26.224924.5293@eci386.uucp> woods@eci386.UUCP (That's ME) writes: >>>> Second, a leading '//' with a special meaning is a tremendous KLUDGE! >>>> It's even worse than "machine_A:/"! >>> >>> Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge. >>> Your syntax attaches special to another character. With the // syntax, >>> the special chars remain limited to / and null. >> I see '//' as a huge kludge, 'cause it special-cases the meaning >> of two consecutive slashes when they appear at the beginning of a >> line. This goes directly against the understood meaning of >> consecutive slashes (i.e. scrunch them into one slash). >Agreed. It is too easy to generate consecutive `/'s by accident, >and I would prefer that they map to just one as they do now. Also agreed. '//' is a huge kludge. Such as when you have a list of directories for something (a la $PATH). The natural thing to do is snatch a directory from the $PATH, append '/desired.filename', and see if you can 'access()' that file, then go back & snatch another directory, etc. The problem is: What if one of the desired directories is '/'. Then you append another '/', creating the proposed "magic double slash" situation. (Obviously you can check, but it's much easier to have the kernel coalesce adjacent slashes). [...deleted stuff...] >> I want to be able to put >> directory hierarchies anywhere I please, whether they are on a >> remote machine, or local. That's part of what network tranparency >> for filesystems is all about. The meaning of "mounting a >> filesystem" should be exactly the same, be it a local mount of a >> physically local disk, or a remote mount of a filesystem >> advertised to the network. >I disagree here. I feel that they should be mounted in a standard place. >We use NFS here, and are considering the following scheme. >Every file should be accessible via /<host>/<path>, where <path> is >the pathname as it would appear on <host>. Local filesystems can be >remounted on /<name_of_local_host>/<path>. Perhaps I'm missing the point. Do you mean that you _REQUIRE_ the "/<host>/<path>" situation, or are you _SUGGESTING_ it? If "require", seems you're putting too much policy into the kernel. Ought we not to desire a clean separation between Mechanism and Policy? That's what I like about the Un*x FS: there are only *2* special chars: '/' and '\0'. ALL other chars are treated equally by the Kernel (naturally the shell enforces a bit more policy, but using a particular shell is my choice). The point is: the Kernel provides as much mechanism as possible, but as little policy as possible. Would we agree that Security concerns are exceptions to this? Ie: Security is clearly a _policy_ issue, right?? Yet it appears[?] to belong in the Kernel, right?? Marshall -- ________________________________________________________________ Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
jmagee@fenix.UUCP (Jim Magee) (06/08/89)
In article <338@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes: |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. I agree that having to mount another filesystem to get at network directories is an awful way to do things. First it requires root privilege to do it, and it also fills up kernel mount tables with lots of NFS mounts. I have to disagree with the // concept though. It adds special meaning to something that in BSD just means /. I know of several programs that were written for BSD that just tack the / out front of a directory and would break with this new interpretation of //. (Please, I didn't write them so don't blame me for this one) Mach introduces a better concept, I think. It uses a more robust symbolic link mechanism that allows you create a symbolic link to something on the network. (I think it is Mach, but I can't find it in the manual, maybe it is in the Andrew Filesystem) This seems to be a better solution. Every user can create one, they are stored in the filesystem not the kernel, you can mount a file or a directory (try that with //), and the concept can be expanded to specify the network filesystem type that you want. -- Jim Magee - Unix Development | Encore Computer Corp jmagee@gould.com | 6901 W Sunrise Blvd MS407 ...!uunet!gould!jmagee | Ft Lauderdale, FL 33313 "I speak for nobody..." | (305) 587-2900 x4925
rec@dg.dg.com (Robert Cousins) (06/08/89)
In article <4438@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <40062@cmcl2.NYU.EDU>, edler@cmcl2.NYU.EDU (Jan Edler) writes: >> We've been a bit indecisive about the exact form of pathname >> extension. My current preference is to say that "/@" at the beginning >> of a pathname, followed by a file descriptor number (as a string of >> digits) and a "/", means to take the object referred to by the file >> descriptor as the search starting point. >This is an intriguing idea. I, myself, would prefer to make '@' by itself >at the beginning of a file name a special token. This solves the problem >of files beginning with @ in /tmp... >I'd generalise it beyond directories, too. That way you could open '@5' to >clone a descriptor. This is similar to the /dev/fd/5 syntax described by >people using more recent bell releases, except that you can't chdir to >/dev/fd/5/workdir. >-- >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. >Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. >Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. AOS/VS from Data General has the concept of default files. These files being with the character @ and are "special." Whenever a program attempts to open @output, the OS converts this file name to an already established file name (the terminal by default). However, the value of @output can be changed at the CLI (shell) level. This serves a function similar to a cross between environment variables and I/O redirection. It is, however, VERY useful for many tasks. Perhaps a better solution would be to use some special character to signal a non-filesystem request to be passed to a another task. THis would allow special filesystems to be implemented as dedicated tasks and then used transparently. The task would simply initialize and then advertise itself to the OS in some standard fashion. Special networks, unique hardware and all manner of new features could be built on top of the current semantics then. To do this, however, I would suggest something of the form: <specialcharacter><specialtaskadvertisedname>/<path> so that path semantics can be clearly used along with multiple adversting tasks. Just my $.02 worth. Robert Cousins Dept. Mgr, Workstation Dev't. Data General Corp. Speaking for myself alone.
peter@ficc.uu.net (Peter da Silva) (06/09/89)
In article <350@torch.UUCP>, richard@torch.UUCP (Richard Nuttall) writes: > 1) The system will use a widely available UI, which will be bundled > in with the system. This will consist of (e.g. X, with PEX), as a > portability layer, and a UI style on top (MOTIF? but this would > probably cost money :-) ). > Something like what the NeXT machine came with. God, I'd hope they either roll their own, use something tight like MGR, or reverse-engineer NeWS. X is the Fortran of windowing systems. No, it's worse... it's the Assembly. [ fast context switching, fast IPC ] Sounds like a job for Mach. > 3) The "average" user is not interested in the console, and wants > to have a powerfull interface immediately available on boot up > ("O.K., so configure the system" I hear you say). If you always > have this interface available, the OS can use it to communicate > with the user, i.e with popup menus, message boxes, dialog > boxes, and configuration panels. For minimal security the machine should require a login sequence on the console anyway, just put this stuff in .profile. There's no point having a fancy windowing system if all you have in it is an xterm window displaying /etc/issue. And you can always provide a program to automatically put something fancier in the :console: line in /etc/inittab. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
mcm@rti.UUCP (Mike Mitchell) (06/09/89)
I have been reading the articles proposing different symantics for accessing
remote systems with some amusement. Some say '//host', others '@/host' or
'/@host' or other varients. All require some hackery to the name parsing
routines in the kernel (namei) so that it recognises some new syntax. Why
not use the notation '/../system'? There have been distributed systems using
this form since at least 1982. An example of one is described in "The Newcastle
Connection - or UNIXes of the World Unite," Software - Practice and Experience,
vol. 12, December 1982.
Let me explain a bit about the '/../system' symantic. The '/' is your normal
root, right? What is the convention for directory entries '.' and '..' in V7,
System V, and BSD unix systems? Isn't '.' just a hard link to the current
directory? Isn't '..' just a hard link to the parent of the current directory?
Now in the directory called '/', the entry '..' is a hard link to the current
directory also. What happens if you unlink the '..' entry in the '/' directory
and mkdir a directory called '..'? I'll tell you what happens. You get a
directory called '..' accessible from '/'. You can now chdir to '/..' and
get to a new directory. Put anything you want in that directory. Put
symbolic links pointing to NFS systems there. Put mount points for NFS there.
Put the '/dev/net/systemname' character/block devices there. It really doesn't
matter what you put there, because it is just another directory. UNIX users
are used to '..' meaning go up a directory. To go to another system, you should
go above the root on your own system, then down to another one ('/../system').
It all just makes sense.
Of course, if you want to extend a local group of systems into a larger
collection of systems, just add another '..' directory to the '/..' directory.
Then the hierarchy could be like '/../nearsystem', '/../../virgina/system',
'/../../oregon/system', '/../../../england/london/system', or any other kind
of subdivision. The tree could just keep going up.peter@ficc.uu.net (Peter da Silva) (06/10/89)
In article <190@dg.dg.com>, rec@dg.dg.com (Robert Cousins) writes: > Perhaps a better solution would be to use some special character to > signal a non-filesystem request to be passed to a another task. > <specialcharacter><specialtaskadvertisedname>/<path> This is exactly how AmigaDOS handlers work. The syntax is slightly different: <specialhandlername>:<path> which really wouldn't fly in UNIX. The <specialhandlername> resolves into a message port that accepts requests like "Open Old File", "Open New File", "Read", and so on... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
douglas@dekalb.UUCP (Douglas B. Jones) (06/13/89)
In article <16463@bellcore.bellcore.com> sjs@ctt.bellcore.com (Stan Switzer) writes: >In article <8380@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >> James Buster asks what kinds of things should be in th GNU kernel: >> >> > Networking: NFS? RFS? Something better? [deleted] >> 3) If a file cannot be accessed because the system it is on is >> down or unreachable, the user should be notified quickly. [deleted] >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 sjs@ctt.bellcore.com Some of use don't have access to workstation, but are useing dumb terminals. So, if your last statement of "useing pictures and gestures" is a reference to the graphical abilaties of workstations, some of use would be left out in the cold. [the below are filler lines for the postnews message about more old text than new text] -- Doulas B. Jones douglas@dekalb Academic Computer Center or gatech!dekalb!douglas DeKalb College 555 N. Indian Creek Drive/Clarkston, Ga. 30021
allbery@ncoast.ORG (Brandon S. Allbery) (06/14/89)
As quoted from <190@dg.dg.com> by rec@dg.dg.com (Robert Cousins): +--------------- | In article <4438@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: | >This is an intriguing idea. I, myself, would prefer to make '@' by itself | >at the beginning of a file name a special token. This solves the problem | >of files beginning with @ in /tmp... +--------------- Gag me with a Worknet. Altos's network scheme uses @ as a magic character (a super-root, corresponding roughly to // in Apollo networking). I've found it to be something of a pain. I would suggest something like a file system switch-accessible method: mount a "filesystem" which accesses file descriptors, or "default" devices, or etc. +--------------- | AOS/VS from Data General has the concept of default files. These files | being with the character @ and are "special." Whenever a program attempts | to open @output, the OS converts this file name to an already established | file name (the terminal by default). However, the value of @output can | be changed at the CLI (shell) level. This serves a function similar to | a cross between environment variables and I/O redirection. It is, however, | VERY useful for many tasks. +--------------- //GO.SYSIN DD * Yuck. One small step backwards for IBM, one giant leap backwards for operating systems. +--------------- | Perhaps a better solution would be to use some special character to | signal a non-filesystem request to be passed to a another task. THis | would allow special filesystems to be implemented as dedicated tasks | and then used transparently. The task would simply initialize and then +--------------- I still like the FSS. It would, of course, be nice if the FSS entries could be implemented as separate processes, and have the FSS be dynamically modifiable; then you could "advertize" (i.e. put into the FSS) a new "filesystem" type, whether it be a real filesystem, /proc, or whatever, and access it as part of the directory tree. Isn't Mach supposed to be able to do this to some extent? ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@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
fox@marlow.uucp (Paul Fox) (06/15/89)
I would like a system-call something like this: signal(SIGSCHED, my_scheduling_routine); what this means is that every time a process is rescheduled, the now running process would start at the same address. This function 'my_scheduling_routine' can then invoke its own private scheduler. This is the core functionality required for 'threads'. If this signal isnt setup, then a process simply resumes from where it left off. This means that the kernel maybe has a very simplistic scheduler which schedules processes (preferably one like RSTS/E), and threads can be scheduler by a piece of library code or rewritten as your heart desires. It would sure be nice to have the PDP-10/TOPS-10 like concept of a gettab table. Instead of having to look at symbol tables to work out where things are in /dev/mem to see the status of the system it would be nice to have a very fast and efficient mechanism to see whats going on the kernel. Maybe map the kernel address space into user space in read-only mode (a la VMS ?). Definitely want process tracing a la SunOS 4 or better. Even better still is some form of kernel tracing - eg watch all file system accesses which fail with EPERM, etc. This gives us the ability to build our own security access monitors. Probably more things as I think about them.... Oh yeah and finally...orthogonality. I dont want a million and one different configuration files which try to maintain compatability with SysV or BSD just for the hell of it. Make everything look the same - that way I can understand what a file is for or how to modify it without RTFM. -- ===================== Reuters Ltd PLC, Tel: +44 628 891313 x. 212 Westthorpe House, UUCP: fox%marlow.uucp@idec.stc.co.uk Little Marlow, Bucks, England SL7 3RQ
dsill@relay.nswc.navy.mil (06/17/89)
>From: Peter da Silva <peter@ficc.uu.net> > >... Any sort of fancy new command option scheme [will never fly in Japan]. Why not? And why are we suddenly so concerned about internationalization? -Dave (dsill@relay.nswc.navy.mil)
paul@moncam.co.uk (Paul Hudson) (06/20/89)
In article <20037@adm.BRL.MIL>, dsill@relay.nswc.navy.mil writes: > >From: Peter da Silva <peter@ficc.uu.net> > >... Any sort of fancy new command option scheme [will never fly in Japan]. > Why not? And why are we suddenly so concerned about internationalization? Becuase not all users of a future GNU OS will live in ths US, or use English as their first language. Stop being so parochial. Since we have a chance to remove some of the stupid retrictions in the existing stuff, let's do so. 8bit characters everywhere. Locale-specific messages. Why not? Properly done it shold have little impact on what the US version will be like, so you shouldn't mind. Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket" -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"
domo@riddle.UUCP (Dominic Dunlop) (06/22/89)
In article <205@marvin.moncam.co.uk> paul@moncam.co.uk (Paul Hudson) writes: >In article <20037@adm.BRL.MIL>, dsill@relay.nswc.navy.mil writes: >> >From: Peter da Silva <peter@ficc.uu.net> >> >... Any sort of fancy new command option scheme [will never fly in Japan]. > >> Why not? And why are we suddenly so concerned about internationalization? > >Becuase not all users of a future GNU OS will live in ths US, or use English >as their first language. Stop being so parochial. Yes. I guess a product of the Free Software Foundation's not going to do too much to fix the trade imbalance between the US and Japan, even if it can handle Japanese characters... > >Since we have a chance to remove some of the stupid retrictions in the >existing stuff, let's do so. 8bit characters everywhere. Locale-specific >messages. Why not? Properly done it shold have little impact on what the US >version will be like, so you shouldn't mind. Agreed, except that eight-bit cleanliness on its own is not likely to be sufficient in the long term: ISO is, believe it or not, working on a ``multi-octet coded character set'' (draft international standard 10646), which is 32 bits wide (although they've only worked out what to do with 24 of them so far). Reading it, it seems that the cleanest way to implement anything which processes data (as opposed to communicating or storing data) is to have a module which delivers a constant-width 32-bit version to its input. This allows transmission and storage to use more compact forms laced with nasty things like shift sequences, while hiding these details from most programs. Thirty-two bit cleanliness, anyone? Those still feeling parochial may care to reflect on the fact that serious users of troff regularly exceed the bounds of an eight bit character set, never mind seven, even when writing English, just by using \(bu, \(34, and so on. _Wouldn't it be nice_ to get away from all those illegible escape sequences? (Of course, we won't: troff is itself a de-facto standard, and so we're stuck with it the way it is -- although see _An Extension to the troff Character Set for Europe_ by Keizer, Simonsen and Akkerhuis in the Summer 1989 European UNIX systems user Group Newsletter.) Seriously, though, multi-byte character sets are a hot and knotty topic for both UNIX and C. If you're in the least bit interested, watch comp.std.internat. -- Dominic Dunlop The Standard Answer Ltd., using Sphinx' facilities (for which much thanks) domo@sphinx.co.uk
stripes@wam.UMD.EDU (06/28/89)
I missed the orignal post, and some of the replys. If this is off base
feel free to flame me in mail, but please don't waste bandwidth by trying
to humiliate me in front of the world...
I would like to see a few extra protection bits in the new Kernal. A bit
for append-only (the kernal fseeks to the end of the file before each write).
This could be used for all sorts of logs where you are more concerened with
preserveing past history then makeing shure that the new entrys are Ok.
(or for game hi-scores, or for people to drop messages into, or whatever).
It also seem somehow "cleaner" to set the append bit for a directory to
indicate that people can create files here, but not unlink/move other's files
(current use of sticky bit), but I'll leave the meaning of append for
directorys to others...
(it should be settable for user/group/world, and if GNU supports it for
the rwx bits, for any given set of users; if not I have another request:
let unprivlaged account create and maintain groups somehow...)
The append bit would make it a little less nessary to have set-uid programs.
Something that is not as important to me is the ability for Mr root to be
able to flip a bit on a file and have it removed from a users disk-quota.
(i.e. if someone has a log file that gets appended to and it offen gets
HUGE, he might be able to get the "no-quota" bit set). I'm not very
big on this idea, becuse you can do a sym-link to a non-quotaed system,
but it is once again "cleaner".
I leave the semantics of the "no-quota" bit on directorys up to the
"interested student".
I would also like to be able to have the Kernal send me a signal
whenenver a file (or set of files & directorys) that I ask about
are altered. This could eliminate polling in a number of places...
--
stripes@wam.umd.edu "Security for Unix is like
Josh_Osborne@Real_World,The Mutitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
"A career is great, but you can't run your fingers through it's hair"norstar@tnl.UUCP (Daniel Ray) (06/30/89)
In article <8906272337.AA24210@cscwam.UMD.EDU>, stripes@wam.UMD.EDU writes: > ... > I would like to see a few extra protection bits in the new Kernal. A bit > for append-only (the kernal fseeks to the end of the file before each write). > This could be used for all sorts of logs where you are more concerened with > preserveing past history then makeing shure that the new entrys are Ok. > (or for game hi-scores, or for people to drop messages into, or whatever). > It also seem somehow "cleaner" to set the append bit for a directory to > indicate that people can create files here, but not unlink/move other's files > ... This is a great idea, I think! A while back I thought of something like this which would work as follows: 1. A new (or new use of a) directory permission bit, such as using SUID/SGID or something new, would designate the dir as "append only except edit in single user mode". This would apply to root as well. So, audit trails and logfiles could not be modified except when the machine was brought down to single user mode at the local console. Files in the dir could be appended to, however, if the mode on the file permitted writes. Existing data could not be modified by anyone in multiuser mode. 2. The permission bit could only be unset in single-user mode where the person has local access to the cpu. 3. If someone broke into the machine and became root remotely, they could not erase their logged attempts to clean up after the breakin. One of the big flaws of UNIX is that one root can do battle with all others, so the breakin root can take over. The kernel should enforce some accesses based on locality to the physical machine instead of by login/su validation. norstar The Northern Lights, Burlington Vermont | You are down tnl dialins: 802-865-3614 at 300-2400 bps. ` | / down down ------------------------------------------ --- * --- the dark uucp: uunet!uvm-gen!tnl!norstar or / | . black waters. {decvax,linus}!dartvax!uvm-gen!tnl!norstar |
dworkin@Solbourne.COM (Dieter Muller) (07/05/89)
I'd *really* like a sane tty driver. However, lacking that, at least generalize the concept of ``this key generates a SIGTSTP'' to ``this key generates a user-specified signal.'' Kinda like TOPS-20's tty driver, where you could do the equivalent of: ^T -> SIGUSR1 ^A -> SIGALRM ^Z -> SIGTSTP ^E -> SIGTSTP ^C -> SIGTERM ^B -> SIGKILL (Yeah, I know that's not how it really worked, but you could fake it without much effort, and this would be even more general. RMS has already said GNU isn't for `little' machines, so a lookup table in the tty driver wouldn't be too bad.) Dieter
dsill@relay.nswc.navy.mil (07/07/89)
>Becuase not all users of a future GNU OS will live in ths US, or use English >as their first language. Stop being so parochial. Pardon me, but I don't remember saying I thought GNU should *not* be international. >Since we have a chance to remove some of the stupid retrictions in the >existing stuff, let's do so. 8bit characters everywhere. Locale-specific >messages. Why not? Properly done it shold have little impact on what the US >version will be like, so you shouldn't mind. Eight-bit characters?! Stop being so parochial. What about Korea/China/Japan/etc.? If we're going to fix it, let's fix it so it stays fixed. 32-bits ought to do it. I really don't know what to think about internationalization. I don't think we can ignore it, but I don't think we can lick it yet, either. Eight bit characters sure ain't gonna do it. -Dave Sill (dsill@relay.nswc.navy.mil)
vsh@etnibsd.UUCP (Steve Harris) (07/07/89)
In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: >I'd *really* like a sane tty driver. Hear hear!! At a former job we talked a lot about how we would rewrite the tty driver. One idea was to give the user, via ioctl's, access to the uart (or whatever serial-line multiplexer you have). One ioctl to get the uart settings (in a bit vector), another to set them, and another to have the driver(??) send you a signal (for which you would have to write the appropriate handler) whenever any of the bits changed (e.g., DTR was deasserted). Standard configurations (handlers) would be privided in a library. Of course, one would be limited by the capabilities of the uart, but the design would assume total access to be possible. A second idea is "copy-on-write symbolic links" -- I have a symlink: bar -> foo When I write to it, a regular file "bar" is created (the symlink is destroyed), the contents of foo (up to the current file-pointer-offset) are copied to bar, and the write takes place. I'm not sure what happens if foo is not a regular file. -- Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh
ccs@lazlo.UUCP (Clifford C. Skolnick) (07/07/89)
In article <214@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes: |In article <8906272337.AA24210@cscwam.UMD.EDU>, stripes@wam.UMD.EDU writes: |> ... |> I would like to see a few extra protection bits in the new Kernal. A bit |> for append-only (the kernal fseeks to the end of the file before each write). | | 1. A new (or new use of a) directory permission bit, such as using SUID/SGID |or something new, would designate the dir as "append only except edit in |single user mode". This would apply to root as well. So, audit trails and |logfiles could not be modified except when the machine was brought down to |single user mode at the local console. Files in the dir could be appended |to, however, if the mode on the file permitted writes. Existing data could |not be modified by anyone in multiuser mode. If I was the superuser, I could just wipe out the raw disk devices. The only way this will work is to use an on-line printer. The whole concept of a super-user is the problem. I wish I had a better solution to offer, but... Cliff -- "I'd rather stay here with all the madmen, than perish with the sad man roaming free" -- David Bowie "Life is a test, only a test. If it was real, you would have been given much better instructions." Clifford C. Skolnick / (716)427-8046 / ccs@lazlo.UUCP
andrew@alice.UUCP (Andrew Hume) (07/09/89)
In article <1050@etnibsd.UUCP>, vsh@etnibsd.UUCP (Steve Harris) writes: > In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes: > >I'd *really* like a sane tty driver. > > Hear hear!! At a former job we talked a lot about how we would rewrite > the tty driver. One idea was to give the user, via ioctl's, access to > the uart (or whatever serial-line multiplexer you have). One ioctl to and so on..... this is plainly false advertising. it is plausible to give complete control of a uart to a user. it is NOT plausible to do so under the guise of a sane tty driver. normally, you would implement a new device (say /dev/uart).
pcg@aber-cs.UUCP (Piercarlo Grandi) (07/22/89)
In article <13750@ncoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery) writes:
I still like the FSS. It would, of course, be nice if the FSS entries
could be implemented as separate processes, and have the FSS be dynamically
modifiable; then you could "advertize" (i.e. put into the FSS) a new
"filesystem" type, whether it be a real filesystem, /proc, or whatever, and
access it as part of the directory tree.
Isn't Mach supposed to be able to do this to some extent?
Much better than this actually. Briefly, all access to data is thru ports;
you are not allowed to know what is on the other side of the port, and
ports can be transmitted across a port. You can ask the os port for a port
to the filesystem, and the filesystem port for a port to the file. You
can have multiple filesystems running on your machine, and you can even them
use concurrently from the same program. Directories can be ports that look
exactly like filesystem ports, which makes a lot of funny things possible.
This is not a precise description, but gives a gist of the power of having
unrestricted transmissible opaque capabilities. There are several papers
on Mach that describe the idea and its implications.
Historical notes: BSD has *two* similar facilities; one is the unimplemented
used defined domain capability, and the other is the idea tha in the UNIX
domain it is possible (well, it was buggy) to transmit file descriptors.
Using just this, it is possible to have several filesystem processes, a name
service process, with a well known Unix domain socket name. You ask the name
server for a socket/fd to one of the file servers, and then you can send on
this socket an open request for a file, and the filesystem process will
return a socket/fd for the open file, etc... Same for having multiple
TCP/IP, XNS, etc... servers outside the kernel. Like Mach, but without the
careful tuning to make this efficient.
Streams can also pass file descriptors in messages, and thus gain the same
flexibility. You can effectively push user processes on a stream, (above the
stream head, not below it, though) by this technique.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpeter@ficc.uu.net (Peter da Silva) (07/22/89)
In article <20037@adm.BRL.MIL>, dsill@relay.nswc.navy.mil writes: > >From: Peter da Silva <peter@ficc.uu.net> > >... Any sort of fancy new command option scheme [will never fly in Japan]. > Why not? I don't know... you didn't leave enough of the message for me to figure out what's going on. I suspect, though, that you're combining two seperate things here: fancy new command option schemes, and restricted file names. The first is bad because it will break working scripts (you think it's tough to install News today?). The second because different countries have different definitions of what funny characters in file names *are*. > And why are we suddenly so concerned about internationalization? I'm an international. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
gaf@uucs1.UUCP (gaf) (08/04/89)
Something I'd like in an OS is an all encompassing type of select() which would let me take data (events) from a variety of sources in the same fashion. For example, I'd like to wait on a semaphore, a message queue, a pipe, and a TCP socket all at once (okay, this is a contrived example). A lot of code I write ends up being event driven, and being able to wait on a variety of different events at once would be useful. It would be nicer still to be able to take (read) the events in a common fashion. A message queue might be read in a way similar to a file, but with some message selection criteria attached. The method of data delivery could be chosen according to performance needs (speed [message] vs. integrity [file]), but would be as transparent as possible to the program. Just a thought. -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf Newsgroups: comp.unix.wizards,gnu.discuss Subject: Re: What kinds of things would you want in the GNU OS? Summary: Expires: Sender: Reply-To: gaf@uucs1.UUCP () Followup-To: Distribution: Organization: UUCS inc., Phoenix Az Keywords: Something I'd like in an OS is an all encompassing type of select() which would let me take data (events) from a variety of sources in the same fashion. For example, I'd like to wait on a semaphore, a message queue, a pipe, and a TCP socket all at once (okay, this is a contrived example). A lot of code I write ends up being event driven, and being able to wait on a variety of different events at once would be useful. It would be nicer still to be able to take (read) the events in a common fashion. A message queue might be read in a way similar to a file, but with some message selection criteria attached. The method of data delivery could be chosen according to performance needs (speed [message] vs. integrity [file]), but would be as transparent as possible to the program. Just a thought. -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
jeffrey@algor2.uu.net (Jeffrey Kegler) (08/04/89)
I have (obviously) taken some time to this over because it is a big question, and one likely to be important in our field. In order of importance, I think the features of a GNU OS should be: 1) POSIX and X/OPEN compatibility 2) SVID compatibility 3) Berkeley compatibility 4) Some solution to the problem of kernel size, such as a message passing mini-kernel with configurable modules. 5) Other new features I give new features a low ranking, not because I do not think many would not be nice, or even necessary, but because I think the first goal has to be to get people using the GNU OS. Because it will be open, it will immediately attract a lot of research attention. Many a PhD thesis on some aspect of operating systems will feature an implementation in GNU OS. So, once GNU OS takes off, a cornucopia of new features should quickly become available. When AT&T stopped shipping source with every UNIX the dark ages of UNIX began. The day GNU OS is announced may well mark the end of the Dark Ages. So the first object should be to get GNU OS a critical mass of acceptance. In justifying use of GNU OS for their development to my clients, compatibility with industry standards will be crucial. I gave POSIX and X/Open top billing because they are real standards, not descriptions of implementations. I ranked SVID above Berkeley not as a technical judgement, but because SVID is more widely accepted as standard commercially, in my opinion. The kernel size problem has become so major that it outranks all other new features in my mind. What with networking, the increasing variety and complexity of devices, etc., having to put all kernel functions into a single executable is getting very burdensome. V6 UNIX was elegant. The kernel I now run is an ugly ungainly thing. I would like to see the elegance of V6 return (without losing all the new features added since V6). Since GNU OS is done with volunteer labor, a certain amount of work on new research features may be necessary as payment to the type of talent the project will attract. Except as necessitated by this consideration, I think new features should be excluded from the first release of GNU OS. From what I can gather of what is going on at FSF, they are well ahead of me on the above considerations, and I feel that we can look forward to great things with the release of GNU OS. -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (08/05/89)
I think the more immediate question is *what* would you like the GNU OS to run on? Ultimately, everything, but we've got to pick a platform and start hacking soon, or all we'll have is a bunch of utilitys. Sun's would be an obvious choice, but what about the MMU? Does anyone without proprietary knowledge know what it does? Can we just poke numbers at it and see what happens? Root Boy Jim Have GNU, Will Travel.
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (08/06/89)
In article <20514@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: >I think the more immediate question is *what* would you like the GNU >OS to run on? [...] Sun's would be an obvious choice, but what >about the MMU? Does anyone without proprietary knowledge know what >it does? There are much more "open" platforms than Suns. A 386 PC clone has well defined *and* documented register layouts. It is also quite a bit cheaper (due largely to competition and the fact that anyone can design a PC workalike due to the "open" specs.) Wouldn't it be ironic to spend a lot of effort to write a free kernel for a proprietary hardware base? -wolfgang Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) TEL: (703) 768-2640 UUCP: mit-eddie!mgm.mit.edu!wolfgang
bzs@BU-CS.BU.EDU (Barry Shein) (08/07/89)
>Sun's would be an obvious choice, but what about the MMU? >Does anyone without proprietary knowledge know what it does? >Can we just poke numbers at it and see what happens? > > Root Boy Jim I would imagine the 68030 based machines (eg. 3/80) make this moot since the MMU is integral to the chip so should conform to Motorola docs. In that class I'd be more interested in looking towards the SPARC and MIPS based machines. I have heard rumors that the '386 (et al) machines come up as a likely platform. Not because they're particularly wonderful but because they're cheap and plentiful at the moment. An adequate no-name machine can be had for around $5K, including disk etc (certainly adequate for kernel devpt projects, more memory and disk may be needed in final user configurations but those prices are coming down rapidly so anticipating those curves seems prudent, with 4Mb chips coming and general disk prices I'd guess 386/16MB/300MB machines will be available in the $5K range in a year or so, '486 for a little more.) Now someone will say "...and you will need it..." (ie. 16MB/300MB), sic transit gloria mundi. -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
peter@ficc.uu.net (Peter da Silva) (08/07/89)
In article <20514@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: > I think the more immediate question is *what* would you like the > GNU OS to run on? The obvious choice is 386-based AT-bus machines. They're ubiquitous, relatively cheap, and pretty well documented. But, knowing RMS, he's likely to go for IBM PC/RTs and Microvaxes just because there are thousands of them at the MIT Athena Project. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
guido@piring.cwi.nl (Guido van Rossum) (08/09/89)
peter@ficc.uu.net (Peter da Silva) writes: >[...] What >I'd really like to see in a future C library standard would be a portable >implementation of: > [...] > context = create_context(context_template); > status = destroy_context(context); > switch_context(context); > >Plus some sort of co-ordination (semaphores, monitors, messages, or >whatever). Multitasking, coroutines, whatever... could be built on >top of this. Because the context switch is implicit you don't get to ^^^^^^^^I assume you mean explicit >deal with race conditions (such as switching context inside of malloc). >You still have to worry about globals, though. A threads interface without synchronization primitives would be a farce. At the very least you need mutexes (binary semaphores). Other mechanisms (sleep/wakeup) are proven to be equivalent. A non-blocking mutex call (atomically test it and set it if not set) is a welcome addition. Timeouts are next (and really a generalization of the non-blocking call). A threads interface that assumes context switching is only done by explicit calls soon becomes a nightmare, because people tend to forget to use the mutexes when they "know" no other threads can execute in the mean time. This assumption is often invalidated by later additions to the code, by things that happen rarely deep inside routines you call, or by debugging options. But the real problem is that you really want to use the same threads paradigm on a true multiprocessor. Both problems are expemplified by the Unix kernel. Oh, on most hardware, mutexes can be made very cheap (a few instructions) in the common case that the mutex is free. I personally believe that you don't need primitives to kill threads or to wait for their completion; but this is really becoming a different thread of discussion. :-) -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net "Repo man has all night, every night."
peter@ficc.uu.net (Peter da Silva) (08/10/89)
I said, I'd like: > > context = create_context(context_template); /* Create a context */ > > status = destroy_context(context); /* Destroy someone else's ctx */ > > switch_context(context); /* Transfer control to context */ Also, I think you'd need: context = my_context(); /* Who am I */ In article <8325@boring.cwi.nl>, guido@piring.cwi.nl (Guido van Rossum) writes: > A threads interface without synchronization primitives would be a farce. I did mean the context switch would be explicit, not implicit. Thanks for pointing that out. Anyway the three (now four) routines above are the main core of the system. They can not be implemented in portable C. Once you have them, you can implement mutexes, or whatever, in portable code. > A non-blocking mutex call (atomically test it and set it if not set) > is a welcome addition. Since context-switching is an explicit action, implementing a non-blocking operation is trivial... you just don't perform a context switch in the middle of it. Let's look at that... > [depending on explicit context switches encourages lazy programming] Probably true, but this interface allows a relatively cheap and easy implementation. It has proven very useful in Forth in real-time programming. Besides, these routines allow you to do more than threads. It gives you simple coroutines (it *is* basically an implementation of coroutines). It also allows you to implement threads without putting semaphores all through the standard I/O library. And you can add routines that make use of threads to an existing program without breaking it. A more powerful interface would be better, but it would also require more than a couple of mutex calls. You'd need to add a scheduler so you knew what context to go to when you're waiting, and so on. Perhaps a test-and-set call should be added, but really once you get that far you're getting more ambitious than I think is necessary for a lot of tasks. > But the real problem is that you really want to > use the same threads paradigm on a true multiprocessor. Both problems > are expemplified by the Unix kernel. What you're saying here is that these threads are not as powerful as you'd like. But they're cheap. And they can be implemented trivially by vendors. > Oh, on most hardware, mutexes can be made very cheap (a few > instructions) in the common case that the mutex is free. But rewriting the standard I/O library to support pre-emptive threads is *expensive*. If the vendor is willing to do this, then they could implement a more powerful set of routines, with a scheduler even. Perhaps you could define the interface for them? > I personally believe that you don't need primitives to kill threads or > to wait for their completion; but this is really becoming a different > thread of discussion. :-) You're right. Notice I didn't provide a mechanism to wait for completion. The only purpose for killing the thread is to free the memory used by that thread's stack and context. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
scs@adam.pika.mit.edu (Steve Summit) (08/13/89)
In article <1989Aug4.080124.26687@algor2.uu.net> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >...I think the features of a GNU OS should be: >4) Some solution to the problem of kernel size... >The kernel size problem has become so major that it outranks all other >new features in my mind. ... V6 UNIX was >elegant. The kernel I now run is an ugly ungainly thing. I would >like to see the elegance of V6 return (without losing all the new >features added since V6). >From what I can gather of what is going on at FSF, they are well ahead >of me on the above considerations... Don't hold your breath. The FSF may be many things, but they don't seem to be too interested in small, minimalist programs. Full-featured code has its price, and the existence of virtual memory makes it easy to pay. (But not free; a friend of mine can't run GNU emacs and a large image-processing application at the same time, because his workstation runs out of swap space.) GNU emacs is nearly twice as big as the 4BSD Unix kernel (which some feel is bloated itself); I am sure that the GNU Unix kernel will rectify this imbalance. Steve Summit scs@adam.pika.mit.edu