>> attributes are managable in a scalable way.
>By recompiling the kernel for each combination?
You must be a doctor of Poly-Sci, because I've never seen
someone lie so much and ignore what people tel them. Big
fat lie.
>> I haven't noticed it being harder or less Unixy.
>Device names, permissions, ownership won't stay put unless extra steps are
>taken. Adds fragile mechanisms to get back what you already get from
>handling a device as a plain file. Need to remember to either recompile the
>kernel or edit a configuration file for permissions.
Big fat lie.
>> Besides, the changes for most drivers seem to be mostly the addition
>> of a parameter to the registration call. And it puts the knowledge
>> for creating devinces in the one place that knows it -- the driver.
>It has to be done for _each_ driver. I'm not saying that this should never
>be done, just that the cost isn't worth the gains in this particular case.
Big fat lie. One solution to many many BIG architectural problems...
>> I haven't seen any other scheme for managing hot-pluggable devices
>> that isn't more complex and less maintainable than devfs.
>MAKEDEV works. No, I don't hot-plug stuff all day. But then again, nobody
>I've ever met does either, so the point is moot.
Maybe your tiny world doesn't need devfs, but it's not an
argument against it.
>I haven't met _anybody_ that does what is touted as THE case in which devfs
>is the ideal solution, so I'll stay unconvinced.
A guy has been continuously posting he uses USB and PCMCIA
all the time, and he as much as HAS to use devfs!0
>> The size of /dev isn't really disk space, it is congnitive space.
>Bingo! And devfs won't enlarge my mind, it will at most shrink /dev. But
>that I can do by hand, or even automatically: Write a scriptlet that checks
>each device in /dev; if it isn't there, delete it.
So do that. Say CONFIG_DEVFS=N, or submit that scriptlet and
stop bragging about your SKILLZ, Dr dumby!!!
>> And given my experience, including devfs in the standard kernel src
>> is a no-brainer. Sure, it's a little rough around the edges, but it
>> won't get better until it is a standard part of the kernel source.
>"It will get better when in the kernel" isn't the right way to advocate a
>patch. This assumes innocent third parties will have to take over the work
>of getting it right.
It isn't wrong now.
>- Impact on security: What if the permission handling machinery goes
> missing or breaks? What new kinds of attacks does this make possible?
> Ways to fix them?
It's an OPTION!!!
>- Impact on administration: "For Linux, unlike any other Unix system,
> devices are managed by...". This hinders people portability.
Devices are managed by the DRIVERS.
>- Impact on software portability: What if this cool foo package needs to
> change permissions on the bar device? On installation? During operation?
Non issue, as you have been told a zillion times.
>- Impact on kernel drivers (discussed above)
Almost a non-issue.
>- Impact on future developments: Say capability-enabled root-less Linux
> distributions. How will capabilities be handled for devices? Now there
> will have to be an all-powerful device manager... want to bet what
> crackers will start to try at after getting into your system?
Why don't you stop spreading FUD and gimme an example?
>Again, /dev might not scale well, but it is a non-problem. I have yet to
>see a machine with hundreds of devices. And the network around here, that
You're in a limited environment, and 640k is enough for you. I
personally am NOT. I have terabytes of disk used by OPS to
think about!
>is certainly made of hundreds of devices, isn't reconfigured willy-nilly.
>Each change does take some work figuring out how it works and then changing
>it. Naming issues (and that is the _only_ thing a devfs can solve) is a
>very minor part here.
Big fat lie.
>And yet again, I do see some advantages in a devfs type system. It's just
>that they are very minor, IMO, and just not worth the extra hassle. No, not
To you.
>extra hassle for the systems user or even administration, hassle for the
>developers. But that one, soner or later, translates into extra hassle for
>the former. Software systems developments in general have shown time and
It isn't a big hassle. Only YOU have said it is.
Stop spreadin falsehood, you poly sci professor!
-Shawn
-
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/