I guess you missed my response:
Answer: way too much! That's why a scsidev or devfs system is
essential.
HPA and I then took our discussion offline. For the public benefit,
the typical RAM consumption of devfs is a few pages. The answer I had
given public was a reference to the fact that with devfs (or scsidev)
you don't need millions of inodes.
> dev_fs uses too much of kernel memory and by doing so inflicts a
> performance hit.
It uses a measly few pages. I don't think this is "too much". As I
also discussed with HPA (quiting myself again):
Yes, having a few extra unswappable pages can potentially hurt
performance. On the other hand, devfs also can improve performance
(both because of less device nodes and a more direct link between
device nodes and device drivers). Which effect is more significant is
unknown at this point.
> Using either tar, or a C program to save and restore permissions,
> user/group ownership, modtimes, etc is a hack.
If needed, devfs can have real persistence to a block device.
> 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>
And quoting my response:
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. I also
see it as a conceptual and administrative overhead. We now have device
information kept in two places: in the source of each driver and in
devices.txt, and has to be synchronised manually. Devfs avoids that
entirely by keeping it in one place: in the driver.
These are not "killer argument" for it, they're just some (small)
reasons in a long list. As I've said in the FAQ, IMHO the totality of
these reasons does show that devfs is a good idea.
Regards,
Richard....
-
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