Re: Locking of serial devices and devfs
On Fri, Jun 22, 2001 at 01:25:25PM +0200, Wichert Akkerman wrote:
> Previously Marcus Brinkmann wrote:
> > Well, nothing requires those numbers to provide any meaningful information.
> > The Hurd supports major/minor numbers for device files, but they usually
> > just contain (0,0). tty works in a different, hurdish way.
>
> How do you lock devices in Hurd then?
Mmh. It is not even clear what this means, in a Hurd context. If you talk
about the /dev/* entries, those are all translators (userspace servers), and
as such virtualized. Of course, many of them use underlying kernel devices
n GNU Mach, or in a more generic context, they access underlying hardware
resources.
You would have a hard time to derive a proper locking mechanism from the
translator settings, because they are so generic. Well, if you just are
concerned about multiple people using the same /dev/ttyS0 or whatever,
stadard locking techniques can be applied. If you are concerned that
/dev/ttyS0 and /dev/foo use the same underlying hardware resource, then it
is the responsibility of the system administrator or the underlying
translators to play fair, I think. There is no generic way to find out if
using /dev/foo and /dev bar (or /path1/foo and /path2/bar even) at the
same time in some special way might conflict. In cases where it does
matter, you have to find a policy for yourself and probably enforce it with
access rights.
I am not sure I answered your question, but one thing jas to be kept in
mind: That there is no central authority for such resources, and as such
there is no central authority how such resources should be accessed or
shared. You can of course implement such a central authority, but by
extension there is no way you can enforce others to use it. It's voluntary.
If you want to loose, you can. (Isn't that the first Unix paradigm anyway ;)
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: