On Fri, Apr 20, 2001 at 10:18:13AM -0700, Bill Studenmund wrote:
> Hmmm... Personally I don't like it. :-) My main objections are: 1) you're
> abusing fhopen - file handle innards are supposed to be opaque. Yes, if we
> [snip]
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.

> If you're doing anything pseudo-filehandle-ish, then you need to be
> root. Restricting it to pid 1, though, won't work. The place where init
> tries to look up /dev/console, it has already forked. So it's not pid 1
> any more.

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.

> If the goal is to fix the problem, I think a cleaner fix is to:
> 
> 1) Have the kernel pass in an open file descriptor on say fd 1 which
> is hooked to the console device. fd 1 and fd 2 weould be fine too.

To do this.. either additional facility needs to be put into the vnode/fd
code to hand-craft file descriptors or init-main.c has to understand way
too much about the inner workings of file descriptors in my opinion.

> 2) in init.c:setctty(), if the revoke failes, we assume that /dev/console
> doesn't exist. We then do a login_tty on fd(0). Otherwise we do what we do
> now.

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.

Mike

-- 
Michael P. Lyle