H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > H. Peter Anvin writes:
> > > Richard Gooch wrote:
> > > >
> > > > Why not? It's a non-suid reservation programme. And it does look like
> > > > some kind of reservation programme is required.
> > >
> > > Why not? Because it relies on winning the race condition, not
> > > solving it. You can bet any number of users is going to run this in
> > > their .logins.
> >
> > How is that different from running a suid-root programme which first
> > checks if the floppy is "unallocated" (i.e. owner root, and hope that
> > root doesn't need to use it, or use a separate database: yuk) and then
> > changes ownerships on the device nodes? You still need to win the
> > race.
> >
> > People will still be able to put this in their ~/.login
>
> This is true, but at least you won't have N scripts banging on the
> CPU at random.
But there's only one script where it makes sense to keep "banging":
the one where you want to hold the reservation. There's no difference
with others banging away trying to win the race, since the suid-root
approach still requires you to bang away (really fast).
I could even argue that banging away with devfs is cheaper, since if
someone else has reserved the floppy, all you need do is stat(2) to
check if you've got it yet (since the inode is already there). With
the suid-approach, you need to run the programme in a loop, which is
more damaging for system performance. A stat(2) loop is just a CPU
hog: it doesn't cause page outs and stuff like that.
And in a way it also makes sense that you have to actively try to hold
your reservation, rather have to remember to unreserve it.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
