[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
On Thu, 6 Aug 1998, Terry L Ridder wrote:
> As others have pointed out.

All your point below have been addressed, with the exception of security,
which is presumably with regards to default permission on devices?
Richard has said it wouldn't be a big deal to add persistance to devfs.

Other than that, your posting old concerns already addressed.

1) Security. I wish someone could expound.

2) devfs uses very little memory. I notice nothing, and do make -j all
the time, so I have a good *feel* for memory over here.

3) The persistance thing: Rich has said in the past that it can be done,
and you don't have to use devfs.

More than likely even the distributions using 2.2 will not use devfs by
default, because many users will find a standard /dev reasonable, and
devfs will still be marked "Experimental".

There are, however, those who like devfs and know it is stabel, clean,
fundamentally the "Right Thing To Do (tm)".

> To quote H. Peter Arvin:
> <Begin Quote>
> Auto device generation can be a security hole, and can be done in user
> space without hogging tons of kernel memory.
> <End Quote>
> To quote H. Peter Arvin again:
> <Begin Quote>
> Counter question: how much kernel memory does it take to
> keep a million devices with all their info (atime, mtime,
> ctime, permissions, ownership all included!)
> <End Quote>
> Note no one from the dev_fs side has answered this question yet.
> dev_fs uses too much of kernel memory and by doing so inflicts a
> performance hit.
> Using either tar, or a C program to save and restore permissions,
> user/group ownership, modtimes, etc is a hack.
> To quote Theodore:
> <Begin Quote>
> As far as searching a list when we open a major number, again this is a
> extremely flawed and weak argument. First of all, the vast majority of
> systems out there will only have less than 16 major devices. A typical
> system has less than 10 major devices. (cat /proc/devices and see!) So
> searching the list is simply not a problem. If searching the list were
> an issue, there are plenty of ways of solving this problem internal to
> the kernel, without needing to make any user-visible changes --- such
> using hash table.
> <End Quote>
> --
> Terry L. Ridder
> Blue Danube Software (Blaue Donau Software)
> "We do not write software, we compose it."
> When the toast is burnt
> and all the milk has turned
> and Captain Crunch is waving farewell
> when the Big One finds you
> may this song remind you that they
> don't serve breakfast in hell
> ==Breakfast==Newsboys
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at

<=========== America Held Hostage ===========>
Day 2025 for the poor and the middle class.
Day 2044 for the rich and the dead.
897 days remaining in the Raw Deal.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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