Date: Mon, 26 Jul 1999 20:39:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Cc: bde@zeta.org.au, tlambert@primenet.com, freebsd-smp@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: SMP + XDM = keyboard lockup Message-ID: <199907262039.NAA04652@usr02.primenet.com> In-Reply-To: <199907240817.RAA18855@zodiac.mech.utsunomiya-u.ac.jp> from "Kazutaka YOKOTA" at Jul 24, 99 05:17:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >>2) Why doesn't getty use O_EXCL on the open, such that if > >> it can't get an exclusive lock, it fails? Worst case > > > >Perhaps because O_EXCL has no effect for devices under BSD (its effect > >is implementation-defined except for regular files). > > Isn't this O_EXLOCK rather than O_EXCL? (open(2)) In any case, we > don't seem to have exclusive lock for non-regular files. (flock(2)) No. The "exclusive use bit" (O_EXCL) was used by the first HDB (Honey-Dan-Ber) UUCP implemetnation, and with the first uugetty implementation, in order to implement bidirectional tty use for UUCP (and others). Here are the (not so) gory details: The lack of locking for non-regular files is an artifact of non-regular vnodes being treated differently (struct fileops: when a vnode isn't really a vnode). The main problem is that the locks are hung, via VFS calls which don't work in specfs, off the underlying backing objects (e.g. a lock list pointer on the in-core copy of the FFS inode for a file). This doesn't work in specfs because it doesn't have real direct access to the backing objects, and those backing objects don't have a lock list pointer in their structures, anyway. A (trivial) change to hang the lock list off the vnode instead would enable both range and file (total available range) locks on non-regular files (sockets, FIFO's, devices, etc.). You would then need to either implement VOP_ADVLOCK in specfs, or you would need to move the locking to a higher layer. Doing the latter is problematic because of a desire for future support for working NFS locking: you still need procedural hooks in NFS to assert the lock request over the wire to the server. The way to get around that particular thorn is to move the VOP_ADVLOCK from a commit-based to a veto-based interface. Then everyone (but NFS, for right now) would just say "approved" to the upper level code. For this to work, you need to assert the lock locally, but not coelesce it until everyone has "approved" it, so you can back it out (if you do not do this, then you can't back it out, since asserting it would result in possible "upgrades" or "downgrades" of lock [R -> W], [W -> R], if the locks were coelesced before a "veto" occurred). Pretty simple, really. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907262039.NAA04652>