The concept of having the devices accessed by userland code via the 
device files is a very fundamental one, though. For your embedded 
applications, why not have a small mfs packed up with the kernel? it is a 
very ugly and gross kludge to hack up the kernel to run without a 
filesystem to find init and some important devices, e.g. /dev/console. don't
kludge the kernel just for that! use an mfs!

isildur

On Fri, 20 Apr 2001, Michael Lyle wrote:
> That's a good point.. I didn't like the fhopen hack much either, hence the
> suggestion for a new system call.
> 
> > ?? While I see how not needing /dev/console will help, the kernel still
> > wants to mount a file system as root. And it wants to run init off of one.
> 
> Yes, but it's trivial for people to work around that if they want to..  The
> main thing is, if you don't have a filesystem, how do you get access to 
> hardware (existing drivers) from user space?  As someone who's done
> development for embedded systems in a past life there's ways I could see
> using this.
> 
> You could grab /dev/console pre-fork-- there's no compelling reason not to.
> However, I like making this kind of facility available to all pid's so that
> if someone wanted to do something clever (e.g. embedded-systemish) they
> could.

use DOS if thats what you want. if there is no filesystem, where would 
you be gettinguserland programs from? or do you propose loading images 
by some workaround to avoid exec() as well?? 

> In my system call version, assuming privilege isn't restricted to pid 1,
> we'd do a login_tty on a special open of character device 0,0.

just use DOS and frob the bits in the display memory, dont kludge UNIX 
up! 


otherwise, just use an mfs and bring a filesystem with you. it's simple, 
easy, and it obviates the need for all these nasty kludges. 

isildur