> > You DO realize that you are lowering the chances of getting devfs
> >into the mainstream kernel by using this kind of an attitude and treating
> >others in this fashion, don't you?
>
> It's technical merit will decide, or methinks maybe Linux isn't as good as
> I once thought.
The idea is to convice others that your idea is a good once. Treating
others disrepectfully is not a good way to convice other people you're right.
> > They aren't files in the sense that they are stored on non-volitile
> >media. As in, in reality, they go away when you shut the machine down, and
> >come back when the machine boots up. If you boot off of a floppy an OS
> that
> >understands the root system, you won't see those files.
>
> They aren't files in terms of your definition, being "blocks of data
> residing
> on physical media, being presented in contiguous fashion via a named node
> called a file", but in the purest sense, they are as much a *special* file
> as anything.
'special' files are files that have special attributes, not that go
away when the power goes off.
> >> Misinformation! Misinformation! Misinformation! Misinformation!
>
> > /dev can be cleaned up using rm(1). devfs at one point used
> tarballs
> >to handle permissions, now it doesn't, it uses a configuration file, which
> >makes it even more strange and un-filesystem like. I don't use a config
> file
> >to specify my permissions on my / partition.
>
> No it didn't. It lets drivers decide, and you can chown/chmod/ln etc to your
> heart's content, but persistence was handled by tar which worked beautifully
> via a standard FILESYSTEM INTERFACE.
No, it was a hack. The permissions were not stored w/ the file. They
were not stored on even the same filesystem that the file was.
> >> So you like it. So do it that way. Don't be an ASSHOLE and say just
> because
> >> you don't like it that it CANT be in the kernel.
> > The same could be said about many things that would be bad to have
> in
> >the kernel.
>
> The saga of device fs involves people who for no better reason than
> emotional
> stupidity reject a better idea, not technical fault. It seems you are
> implying
> the current devfs would be bad to have in the kernel. Cite your reasons.
We've just been going over my reasons.
> >> You can, with userland, just like devfs. You could have it monitor for
> new
> >> devices, and either mount it somewhere and add it to /etc/fstab, or have
> >> user configurable actions to perform for certain classes of
> devices!!!!!!!
>
> > So, what does devfs add then? If it doesn't add anything, then
> there
> >isn't much point in having it.
>
> I was talking about extensions for devfsd, where, I SHOULD have said "when
> devfsd gets awoken by a devfs namespace change, devfsd could..."
Why does devfs have to be mounted then? Sounds like it could do what
it wants without being mounted and trying to play like a filesystem, when it
actually isn't one..
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/