lkml.org 
[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
On Wed, 5 Aug 1998, Theodore Y. Ts'o wrote:

> Indeed, I haven't made any arguments because it's clear the devfs folks
> are fanatical about the subject. My plan was to actually implement a

I am fanatical about a solution to a problem. If you have a better one, I
will use it, despite your objections to the current solution.

> better alternative, not just argue about it. The only reason why I

I am curious, what is the concept in a nutshell for you solution? Is it
/proc like? Really, I am curious!

> broke my silence was to point out that not all of the "Linux Kernel
> Gods" (not my terminology) thought devfs was the greatest thing since
> sliced bread, as one person on the mailing list had incorrectly claimed.

Compared to the problem, a solution is the best thing since sliced bread.
Maybe you can start to see what I mean.

> My best guess is that devfs is more like GGI in terms some folks who
> think its great and some folks who think it's kinda ugly. Obviously
> it's different folks, and different objectives; suffice it to say that
> not every one agrees.

GGI is kinda like SGI's /dev/graphics style devices. It can be done with
some level of stability, and does address some problems. (For one, having
to have root permissions to do X stuff, suid junk, or just plain unstable
userland proggies crashing your machine, eh???)

> Specifically, what is ugly about it? Is it intrinsic in nature, or
> something fixable? Is the design flawed? Then how? Back up your
> complaints with more than "Well, I talked with some unnamed Kernel guys,
> and they said..."
>
> ... I thought you were complaining that I was being "way too
> argumentative". Now you want me to argue about it?

You were argumentative in that you stated devfs is bad and didn't back
yourself up.. You were posting some flamebait, and I was all too happy to
take the bait.

> Well, put simply, (1) it's trying to solve a problem in the kernel for
> which parts can just as easily be solved in user-space; it puts too much
> policy and naming issues in the kernel. (2) The hacks that you need so
> that you can save the user/group ownership and permissions are too ugly
> to contemplate. (3) Device inodes really do need major and minor device
> numbers; programs do look at them, and POSIX guarantees that they exist.

1) Yes, a clean /dev "tree" would solve some of the problems devfs
addresses by being a proc like tree of device nodes in memory.

2) It isn't all that bad. If you use full compatibility mode the only
"hack" is for a save/restore state script to be run in the initscripts.

3) Maj/mins are still there if you configure them to be. Devfs does not
explicitely remove any of that.

4) As far as naming is concerned, no, the kernel should not decide, but
the driver??? I think there's a grey area. The devfs gives consistancy
to the /dev heirarchy.

Let me pose a question:

What if I wanted to go from "Brand X Linux", and they have an *uber* kewl
device naming, and an *uber* kewl /dev tree, that minimizes the number of
inodes in any one directory.

I now want to switch to "Brand Y Linux", and they use their own device
naming scheme and /dev tree setup.

Would it not be a "Good Thing(tm)" to be able to just use devfs if I
wanted to in order to bridge the gap?

> The one problem which devfs is trying to solve which I think is valid is
> the question of device partitions, particularly with SCSI. So the
> solution that I'm working on is a small module which can be installed on
> any kernel (doesn't require a massive kernel patch), which scans all of
> the block devices looking for filesystem superblocks/labels for a wide
> variety of filesystems, and creates a hierarchy of device files inside
> /proc for those filesystems.

Ahhh... I have no objection, but maintain that your solution is like a
mini devfs.

> Hence you would see block devices with names such as
> /proc/volumes/ext2fs/ted_root, and /proc/volumes/ntfs/NT5.0, and so on,
> and you can simply put those names in your /etc/fstab file. This way,
> you're guaranteed to get the right partitions mounted even if someone
> inserts a new disk.

Your solution becomes less beautiful with gargantuanly huge numbers of
devices, at least as I understand it. Where does it get it's names?
(Sorry, I'm pretty busy, I really should just read the source...)

> This is much simpler than putting all devices in /dev into a synthentic
> filesystem such as devfs, which I continue to think is overkill and
> unnecessary. Since it's a loadable kernel module, distributions that
> want to use it don't need to install a patch to the 2.2 kernel, but they
> can just load the module.

I don't think devfs is overkill. Granted, it is a different approach et
all compared to /dev inodes... However, it is a fresh, cleaner,
compatible approach, and they way I for one think OSes should do things.

> If folks are interested in seeing what I've done to date, it's small and
> simple enough that I've appended it below. It's still missing a few
> filesystems, such as NTFS and ISO9660, which is why I haven't released
> it formally up until now.

Hey, man, I'll try it, and hope I prove myself wrong. I had misgivings
about devfs too, before I tried it.

-Shawn
<=========== America Held Hostage ===========>
Day 2023 for the poor and the middle class.
Day 2042 for the rich and the dead.
899 days remaining in the Raw Deal.
<============================================>


-
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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:1.070 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site