Borsenkow Andrej writes:
> >
> > Borsenkow Andrej writes:
> > > I am sorry if this is stupid question but if it should not work if I
> > > understand devfs properly ... I mean these dd's in devfsd.
> > >
> > > What happens is
> > >
> > > User accesses /dev/sda4
> > > |
> > > devfs lookup calls devfsd with LOOKUP
> > > |
> > > devfsd runs dd if=/dev/sda
> > > |
> > > |-----------------------+
> > > | |
> > > devfsd returns to devfs devfs calls devfsd with REGISTER
> > > | |
> > > devfs repeats lookup devfsd creates /dev/sda4
> > > |
> > > devfs returns /dev/sda4?
> > >
> > > So to my eyes there are two independent threads with obvious race
> > > condition here. There is no way known to me to synchronize them. It
> > > assumes second threads completes BEFORE devfs does second lookup. Is
> > > it really garanteed?
> >
> > If I understand your question: you're wondering about races between
> > devfsd and it's child dd process. There are no such races, because
> > devfsd will wait for the child process to finish. Devfsd is
> > explicitely single-threaded (i.e. it waits for children to finish) to
> > avoid any such problems.
> >
>
> Not quite. If it is single threaded the thread looks like:
>
> User lookup /dev/sda4 waits
> |
> devfs calls devfsd with LOOKUP /dev/sda4
> |
> devfsd calls dd
> |
Insert here:
dd does open (/dev/sda, ...)
Block driver initiates a media revalidation
devfs_register (dir, "part4", ...) is called
REGISTER event queued to devfsd
dd closes device
> dd returns
> |
> devfsd acknowledges LOOKUP
> |
devfsd receives REGISTER on "part4"
devfsd makes symlink /dev/sda4
devfsd goes back to sleep (no more events to process)
> devfs repeats lookup /dev/sda4 - but it does not yet exist?
It does now. So devfs returns success to user.
> Please, bear with me. I'd like to be sure I understand how it works and
> that it is not just an accident.
Clear now?
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|