Path: utzoo!attcan!uunet!nuchat!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Keywords: GNU OS features kernel fun!
Message-ID: <4332@ficc.uu.net>
Date: 27 May 89 03:56:09 GMT
References: <106326@sun.Eng.Sun.COM> <1049@snjsn1.SJ.ATE.SLB.COM>
Organization: Xenix Support
Lines: 47

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.