lkml.org 
[lkml]   [1998]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
On Fri, 7 Aug 1998, Richard Gooch wrote:

> I do think that major&minor numbers are conceptually a dirty hack.

But we have to keep them because they are embedded fairly deep
in the standards and the existing application code base.

> Certainly the dcache does speed future accesses up
> enormously. It's also true that millions of inodes in /dev is simply
> unworkable.

So don't do it? Use sub-directories. It isn't that big a deal.

> At the very least a solution like scsidev is required.
> However, scsidev only solves the issue of SCSI devices. USB devices
> are another case looking for a solution.

There is no reason scsidev could not be extended to handle things
other than SCSI. I'll even volunteer to do it if required. However,
I'm not aware of a USB driver for Linux yet and I don't see an
awful lot of USB devices on the market yet.

The one thing a kernel space solution like devfs has over a user
space solution like scsidev is the ability to handle a moving root
filesystem. Is it worth the kernel bloat though? I mean, *I* want
my root fs to be as stable as possible. If it moves my hardware
planning is broken and needs fixing - not Linux.

> I think the USB case is even
> harder, because here you have a case of hot-plugging. While also
> possible with SCSI, it's less common there, so perhaps hot-plugging
> SCSI devices is more likely to be ignored. As I understand it,
> hot-plugging is pretty intrinsic to the ideas of USB, so you can't
> ignore it.

Hot plugging has been with us for *ages*. Remember PCMCIA? All you
need to do is to kick off a "set me up script" when the driver
detects a device change. Or you can trigger it manually. Or even
run a "check and set" from cron :-).

> OK, this is separate from the devfs concept. I've already stated
> several times that I could add persistence to devfs. I could either
> write things to a block device or peek through to the mounted-over
> inodes.
> Would such a change make you feel better?

It sounds hideous :-). It's a hack to correct the fact that the
nodes are stored in a virtual filesystem when they should have
been stored on a physical filesystem to start with.

> I think that the extra layer between device nodes and device drivers
> is an ugly hack. I see the extra level of indirection as unnecessary
> and adding some (small, but avoidable) performance overhead.

Huh???

> As I've said in the FAQ, IMHO the totality of
> these reasons does show that devfs is a good idea.

They show devfs provides one solution to the claimed problems. The
arguments are because (a) there are other lighter weight solutions
with less kernel impact like scsidev which do the vast majority
of what devfs does, and (b) not everyone agrees that the claimed
problems actually exist and they are not documented.

Mike

--
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'


-
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:0.328 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site