Roland: Thanks for the quick response. I fully understand the lack of available development resources. I also think that for the Hurd to be truly usable in today's heterogenous computing environments it must deal with the ubiquity of Microsoft's operating systems. I am not experienced enough with Hurd architecture to develop any conceptual blueprint, but given such a plan I would be willing to work on it. Two of my colleagues are interested in Hurd development as well.
>From a humble user's perspective, I would like to see the following: 1. Support for Samba (i.e. file locking) 2. The ability to obtain device specific information, such as disk geometry. This would correct the fdisk problem and, more importantly, make possible a Hurd installation utility that allows for the management of drive partitions. 3. Changing the way Hurd maps a drive partition, to allow for larger volumes. (I understand some of this has been done, and is in a separate CVS branch.) 4. Corrections to the NFS server, which I have heard tends to lock under duress. I'm also curious about microkernel architecture. I've worked with Mach quite a bit, and in general I support its use with the Hurd. I also know that, in a multiserver environment, the number of IPC messages required decreases performance, because each message operation involves an expensive context switch. MIT developed an "exokernel" a few years back, which essentially provided only an abstraction of the underlying hardware, leaving most traditional operating system services left to execute in user space. Wouldn't it be theoretically possible to implement Mach's process management, memory management, and IPC mechanisms as some form of protected programs running in user space on top of this "exokernel?" I'm not asking anyone to work on this, or even look into it. I'm just curious if such an approach even sounds plausible. By the way, I understand it is a Hurd convention to make /usr a symbolic link to /. May I ask why? Kevin Musick [EMAIL PROTECTED] -----Original Message----- From: Roland McGrath [mailto:[EMAIL PROTECTED] Sent: Saturday, May 27, 2000 3:29 PM To: Kevin Musick Cc: [email protected] Subject: Re: Samba There is not much in the way of file locking available in the Hurd, and in particular we do not have facilities that match the POSIX semantics for fcntl locking, or (I think) the BSD semantics for flock. The specified semantics are not very elegant from a component-model perspective, and thus nontrivial to design Hurd protocols to properly support. We (the core Hurd developers) have discussed some ideas for new Hurd RPCs for locking, but never fully resolved on a plan and the main issue is that noone has had the time to make it a priority thing to work on. If there is active interest by someone who will do the implementation work, then I think we can manage to dig up our thoughts on the issue and figure out a good way to go about it. But I don't know when any of the core Hurd developers might have the time to actually do such an implementation.
