Re: TTY changes to 2.1.65

teunis (teunis@mauve.computersupportcentre.com)
Wed, 3 Dec 1997 19:28:02 -0700 (MST)


On Sat, 29 Nov 1997, Theodore Y. Ts'o wrote:

> Date: Sat, 29 Nov 1997 02:56:49 -0500 (EST)
> From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
>
> No, _you_ think it's a bad idea. Many people have wanted devfs
> for a very long time. It has been coded up twice, including a
> recent reincarnation as "SystemFS". It is in FreeBSD, Solaris,
> and AIX. Linux wouldn't be alone at all.
>
> Let's say it's a contraversial idea. Many people have wanted it, but a
> lot of other people have thought it was an extremely dubious idea.

So make it an optional [reccomend='N' default] setting in the kernel :)
It really WOULD be quite handy :)

> All problems can be solved. FreeBSD uses an invisible filesystem
> that only the kernel can change. When you mount the filesystem,
> you get something like a copy-on-write version of it.
>
> I'd love for Linux to have a union mount capability. Anyone want to
> volnteer ti write it?

I remember a union-mount type system appearing for cdroms....

Allowed a person to write to CD filesystems - the changes were saved to
whatever directory you wanted.

... WAAAAAY back around 1.1.xx (or 1.0.xx)....

And have never seen it since. Whatever happened to it?

> Solaris seems to use tmpfs and loopback mounts, assisted by some
> shell scripts. SystemFS uses a daemon to keep everything together.
> As far as I can tell from a quick look, changes you make to /dev get
> reported to the daemon for long-term non-volatile storage.
>
> Solaris uses a number of different methods, indeed including a user
> daemon which also handles automatically mounting and unmounting
> filesystems. I do agree that a user daemon which automatically handles
> mounting and unmounting filesystems is the right answer for that subset
> of the problem.
>
> There are a lot of people have said, "we want a devfs!"; however, it's
> not clear to me at this point that a lot of kernel-side support is the
> right answer. I'd suggest that someone start by trying to implement a
> user-mode daemon that handled the problems by automatically creating the
> devices in /dev by using mknod().

Perhaps some "hack" relative to kerneld? :)

startup: (d=daemon, k=kernel)
(d) "Hiya. Got any devices?"
(k) "Lets' see... Yup, you have access. Here's a list..."
(d) "Ahh... Thanks"
<later>
(k) "Oh - A new devices' registered. Guess I should let you know?"
(d) "duhhh yup!"

some prog: "I need a device by THIS name!"
(d) "Here it is! All nice and registered into this file"
(in user-fs I guess)

I dunno... (am in strange mood - decided to have fun with protocol
thoughts).

since device registration (and arbitration) is in the kernel anyways, it
could just notify a user daemon (if present) of any new devices... and the
daemon could request a "current list" from the kernel. Haven't a clue
what info should be passed back 'n forth though :)

Ciao, eh? :)
- Teunis