Oh, good, it's just the KDE dead horse; for a moment there I
thought one of the *other* products had a copyright restriction
that would bite vendors.
ObKernelContent: On 2.0.28, I'm playing around with using
flock(LOCK_EX) in libc 5.0.9 to lock modem ports so that mgetty,
uucico, and tip can coexist, and I've noticed that about half the
time mgetty doesn't successfully select() busy file descriptors
that are write locked by other processes. I could see it not
selecting at all (which would destroy a wonderful locking scheme,
but if that's how flock works that's the way the cookie crumbles)
or selecting all the time (Which Would Be Good, because then I
could rid Mastodon of device locks), but half the time seems to be
slightly buggish.
Here's a symopsis of what happens:
mgetty locks the modem, initializes it, drops the lock, then
does an infinite select() on the offending fd.
tip fires up, locks the modem, and talks to it.
About half the time, mgetty returns from the select and behaves
as advertised. The other half of the time, mgetty sits there
like a bump on a log as tip merrily floods data back and forth,
leaving the modem in a state that's _not_ conducive to mgetty
working any more.
Is this a bug? A known bug? A known bug that's fixed in 2.1.x
or a later 2.0.x? An implementation problem that will be fixed
by me building libc 4.8.1 and 5.0.10 with a new flock() scheme?
Bad juju because my development machine is not a fuji laptop?
____
david parsons \bi/ Puzzled in Portland.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu