On Wed, Sep 03, 2003 at 09:31:47AM -0300, brunoacf wrote: > There is some effort to implement > virtual filesystems like procfs and > devfs into the Hurd? Sometime ago I > saw a discussion about "Hurd do not > need procfs" in the mailing lists but > I still believe it would be a good > improvement.
If you say procfs, you are probably thinking about the Linux /proc filesystem. There is some information accessible via the trusted proc server, and for other information in the Hurd you can access tasks directly to get it (see the msgport program, for example - in the L4 port, this includes even basic stuff like inspecting memory). This can theoretically also be done by procfs. But only theoretically. In reality, this would mean that the procfs filesystem contacts the process on your behalf. But this means that if the process is malicious and does block indefinitely on the request, the procfs thread would be stuck. It could use a timeout, but even a small timeout makes a server vulnerable to denial of service attacks. So, there are security issues in the Hurd which make a proc filesystem a suboptimal solution. Only some of the features of a Linux proc filesystem could be provided by such a system wide translator. So, such a translator could be written, but it would usefully be implemented as a translator that should be run by the users themselves, and thus consumes their resources, rather than system wide. Device fs is different. Given the pityful state of device drivers in GNU Mach, this doesn't make much sense today. With the port to L4, we will have a much more dynamic framework, and it will make sense and probably be implemented. Device fs is different because the device drivers are trusted and centralized (as opposed to procfs, where the information is distributed and provided by untrusted sources). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
