strange delays in vc class

strange delays in vc class

[Kay Sievers]

I've some debug output from a patched wait_for_sysfs. But no idea,
what's going wrong here:

01:52:36 wait_for_sysfs[29758]: it took 0 seconds for '/class/vc/' to show up
01:53:19 wait_for_sysfs[29759]: it took 0 seconds for '/class/vc/vcs4' to show up
01:53:27 wait_for_sysfs[29760]: it took 0 seconds for '/class/vc' to show up
01:55:41 wait_for_sysfs[456]: it took 69 seconds for '/class/vc/vcs3' to show up
01:55:41 wait_for_sysfs[3653]: it took 0 seconds for '/class/vc/vcs3' to show up
01:55:41 wait_for_sysfs[3655]: it took 0 seconds for '/class/vc/vcs4' to show up
01:55:41 wait_for_sysfs[3659]: it took 0 seconds for '/class/vc/vcsa3' to show up
01:55:41 wait_for_sysfs[3675]: it took 0 seconds for '/class/vc/vcs3' to show up
01:55:41 wait_for_sysfs[458]: it took 69 seconds for '/class/vc/vcsa3' to show up
01:55:41 wait_for_sysfs[476]: it took 69 seconds for '/class/vc/vcs4' to show up
01:55:41 wait_for_sysfs[3684]: it took 0 seconds for '/class/vc/vcsa3' to show up
01:55:41 wait_for_sysfs[3705]: it took 0 seconds for '/class/vc/vcsa4' to show up
01:55:41 wait_for_sysfs[478]: it took 69 seconds for '/class/vc/vcsa4' to show up
01:55:41 wait_for_sysfs[434]: it took 69 seconds for '/class/vc/vcs2' to show up
01:55:41 wait_for_sysfs[482]: it took 69 seconds for '/class/vc/vcs5' to show up
01:55:41 wait_for_sysfs[484]: it took 69 seconds for '/class/vc/vcsa5' to show up
01:55:41 wait_for_sysfs[3750]: it took 0 seconds for '/class/vc/vcs4' to show up
01:55:41 wait_for_sysfs[3752]: it took 0 seconds for '/class/vc/vcsa4' to show up
01:55:41 wait_for_sysfs[3657]: it took 0 seconds for '/class/vc/vcs5' to show up
01:55:41 wait_for_sysfs[3754]: it took 0 seconds for '/class/vc/vcsa5' to show up
01:55:41 wait_for_sysfs[3764]: it took 0 seconds for '/class/vc/vcs5' to show up
01:55:41 wait_for_sysfs[3766]: it took 0 seconds for '/class/vc/vcsa5' to show up
01:55:41 wait_for_sysfs[3768]: it took 0 seconds for '/class/vc/vcs2' to show up
01:55:41 wait_for_sysfs[506]: it took 69 seconds for '/class/vc/vcsa6' to show up
01:55:41 wait_for_sysfs[436]: it took 69 seconds for '/class/vc/vcsa2' to show up
01:55:41 wait_for_sysfs[3780]: it took 0 seconds for '/class/vc/vcsa2' to show up
01:55:41 wait_for_sysfs[3790]: it took 0 seconds for '/class/vc/vcs2' to show up
01:55:41 wait_for_sysfs[3794]: it took 0 seconds for '/class/vc/vcsa2' to show up
01:55:41 wait_for_sysfs[3800]: it took 0 seconds for '/class/vc/vcs6' to show up
01:55:41 wait_for_sysfs[3802]: it took 0 seconds for '/class/vc/vcsa6' to show up
01:55:41 wait_for_sysfs[504]: it took 69 seconds for '/class/vc/vcs6' to show up
01:55:41 wait_for_sysfs[3812]: it took 0 seconds for '/class/vc/vcs6' to show up
01:55:41 wait_for_sysfs[3814]: it took 0 seconds for '/class/vc/vcsa6' to show up
01:55:50 wait_for_sysfs[526]: it took 78 seconds for '/class/vc/vcsa7' to show up
01:55:50 wait_for_sysfs[524]: it took 78 seconds for '/class/vc/vcs7' to show up
01:55:50 wait_for_sysfs[4227]: it took 0 seconds for '/class/vc/vcs7' to show up
01:55:50 wait_for_sysfs[4229]: it took 0 seconds for '/class/vc/vcsa7' to show up
01:56:37 wait_for_sysfs[546]: it took 125 seconds for '/class/vc/vcs8' to show up
01:56:37 wait_for_sysfs[548]: it took 125 seconds for '/class/vc/vcsa8' to show up

Thanks,
Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Kay Sievers]

On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> I've some debug output from a patched wait_for_sysfs. But no idea,
> what's going wrong here:

Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
for the same device. Only the second event will create the "dev" file we're
looking for. So the first event will spin until the second arrives with the file.

Kay

> 01:55:41 wait_for_sysfs[456]: it took 69 seconds for '/class/vc/vcs3' to show up
> 01:55:41 wait_for_sysfs[3653]: it took 0 seconds for '/class/vc/vcs3' to show up
> 01:55:41 wait_for_sysfs[3655]: it took 0 seconds for '/class/vc/vcs4' to show up
> 01:55:41 wait_for_sysfs[3659]: it took 0 seconds for '/class/vc/vcsa3' to show up
> 01:55:41 wait_for_sysfs[3675]: it took 0 seconds for '/class/vc/vcs3' to show up
> 01:55:41 wait_for_sysfs[458]: it took 69 seconds for '/class/vc/vcsa3' to show up
> 01:55:41 wait_for_sysfs[476]: it took 69 seconds for '/class/vc/vcs4' to show up
> 01:55:41 wait_for_sysfs[3684]: it took 0 seconds for '/class/vc/vcsa3' to show up
> 01:55:41 wait_for_sysfs[3705]: it took 0 seconds for '/class/vc/vcsa4' to show up
> 01:55:41 wait_for_sysfs[478]: it took 69 seconds for '/class/vc/vcsa4' to show up
> 01:55:41 wait_for_sysfs[434]: it took 69 seconds for '/class/vc/vcs2' to show up
> 01:55:41 wait_for_sysfs[482]: it took 69 seconds for '/class/vc/vcs5' to show up
> 01:55:41 wait_for_sysfs[484]: it took 69 seconds for '/class/vc/vcsa5' to show up
> 01:55:41 wait_for_sysfs[3750]: it took 0 seconds for '/class/vc/vcs4' to show up
> 01:55:41 wait_for_sysfs[3752]: it took 0 seconds for '/class/vc/vcsa4' to show up
> 01:55:41 wait_for_sysfs[3657]: it took 0 seconds for '/class/vc/vcs5' to show up
> 01:55:41 wait_for_sysfs[3754]: it took 0 seconds for '/class/vc/vcsa5' to show up
> 01:55:41 wait_for_sysfs[3764]: it took 0 seconds for '/class/vc/vcs5' to show up
> 01:55:41 wait_for_sysfs[3766]: it took 0 seconds for '/class/vc/vcsa5' to show up
> 01:55:41 wait_for_sysfs[3768]: it took 0 seconds for '/class/vc/vcs2' to show up
> 01:55:41 wait_for_sysfs[506]: it took 69 seconds for '/class/vc/vcsa6' to show up
> 01:55:41 wait_for_sysfs[436]: it took 69 seconds for '/class/vc/vcsa2' to show up
> 01:55:41 wait_for_sysfs[3780]: it took 0 seconds for '/class/vc/vcsa2' to show up
> 01:55:41 wait_for_sysfs[3790]: it took 0 seconds for '/class/vc/vcs2' to show up
> 01:55:41 wait_for_sysfs[3794]: it took 0 seconds for '/class/vc/vcsa2' to show up
> 01:55:41 wait_for_sysfs[3800]: it took 0 seconds for '/class/vc/vcs6' to show up
> 01:55:41 wait_for_sysfs[3802]: it took 0 seconds for '/class/vc/vcsa6' to show up
> 01:55:41 wait_for_sysfs[504]: it took 69 seconds for '/class/vc/vcs6' to show up
> 01:55:41 wait_for_sysfs[3812]: it took 0 seconds for '/class/vc/vcs6' to show up
> 01:55:41 wait_for_sysfs[3814]: it took 0 seconds for '/class/vc/vcsa6' to show up
> 01:55:50 wait_for_sysfs[526]: it took 78 seconds for '/class/vc/vcsa7' to show up
> 01:55:50 wait_for_sysfs[524]: it took 78 seconds for '/class/vc/vcs7' to show up
> 01:55:50 wait_for_sysfs[4227]: it took 0 seconds for '/class/vc/vcs7' to show up
> 01:55:50 wait_for_sysfs[4229]: it took 0 seconds for '/class/vc/vcsa7' to show up
> 01:56:37 wait_for_sysfs[546]: it took 125 seconds for '/class/vc/vcs8' to show up
> 01:56:37 wait_for_sysfs[548]: it took 125 seconds for '/class/vc/vcsa8' to show up



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Greg KH]

On Fri, Oct 15, 2004 at 02:23:53AM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> > I've some debug output from a patched wait_for_sysfs. But no idea,
> > what's going wrong here:
> 
> Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
> for the same device. Only the second event will create the "dev" file we're
> looking for. So the first event will spin until the second arrives with the file.

Is this with the -mm tree?  or a "clean" 2.6.9-rc4 kernel?

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Kay Sievers]

On Fri, Oct 15, 2004 at 11:34:33AM -0700, Greg KH wrote:
> On Fri, Oct 15, 2004 at 02:23:53AM +0200, Kay Sievers wrote:
> > On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> > > I've some debug output from a patched wait_for_sysfs. But no idea,
> > > what's going wrong here:
> > 
> > Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
> > for the same device. Only the second event will create the "dev" file we're
> > looking for. So the first event will spin until the second arrives with the file.
> 
> Is this with the -mm tree?  or a "clean" 2.6.9-rc4 kernel?

It happens with a 2.6.8 kernel.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Greg KH]

On Fri, Oct 15, 2004 at 08:48:39PM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 11:34:33AM -0700, Greg KH wrote:
> > On Fri, Oct 15, 2004 at 02:23:53AM +0200, Kay Sievers wrote:
> > > On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> > > > I've some debug output from a patched wait_for_sysfs. But no idea,
> > > > what's going wrong here:
> > > 
> > > Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
> > > for the same device. Only the second event will create the "dev" file we're
> > > looking for. So the first event will spin until the second arrives with the file.
> > 
> > Is this with the -mm tree?  or a "clean" 2.6.9-rc4 kernel?
> 
> It happens with a 2.6.8 kernel.

Ugh.  In looking at the kernel code, I don't see how it could be doing
this.  But the console startup code is a strange beast...

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Kay Sievers]

On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> On Fri, Oct 15, 2004 at 08:48:39PM +0200, Kay Sievers wrote:
> > On Fri, Oct 15, 2004 at 11:34:33AM -0700, Greg KH wrote:
> > > On Fri, Oct 15, 2004 at 02:23:53AM +0200, Kay Sievers wrote:
> > > > On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> > > > > I've some debug output from a patched wait_for_sysfs. But no idea,
> > > > > what's going wrong here:
> > > > 
> > > > Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
> > > > for the same device. Only the second event will create the "dev" file we're
> > > > looking for. So the first event will spin until the second arrives with the file.
> > > 
> > > Is this with the -mm tree?  or a "clean" 2.6.9-rc4 kernel?
> > 
> > It happens with a 2.6.8 kernel.
> 
> Ugh.  In looking at the kernel code, I don't see how it could be doing
> this.  But the console startup code is a strange beast...

I'm getting closer:
This is the sequence I get on bootup:

  SUBSYSTEM=net
  DEVPATH=/class/net/sit0
  SEQNUM&0
  ACTION­d

  SUBSYSTEM=vc
  DEVPATH=/class/vc/vcs4
  SEQNUM&1
  ACTION­d

  SUBSYSTEM=vc
  DEVPATH=/class/vc/vcsa4
  SEQNUM&2
  ACTION­d

  SUBSYSTEM=vc
  DEVPATH=/class/vc/vcs4
  SEQNUM&3
  ACTION=remove

  SUBSYSTEM=vc
  DEVPATH=/class/vc/vcsa4
  SEQNUM&4
  ACTION=remove

  SUBSYSTEM=vc
  DEVPATH=/class/vc/vcs4
  SEQNUM&5
  ACTION­d

  SUBSYSTEM=vc
  DEVPATH=/class/vc/vcsa4
  SEQNUM&6
  ACTION­d

According to the kernel code the vc is created on open() and destroyed
on close() which causes hotplug events.  Seems like the bootup opens and
closes a vc two times for every device.
The close will remove the "dev" file and the wait_for_sysfs from the
add-hotplug will spin and fail or at best will recover with the next
hotplug-add. The "remove" event beats the "add"! We have the same event
serializing problem here, we solved with udevd for udev.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Kay Sievers]

On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> > 
> > Ugh.  In looking at the kernel code, I don't see how it could be doing
> > this.  But the console startup code is a strange beast...
> 
> The close will remove the "dev" file and the wait_for_sysfs from the
> add-hotplug will spin and fail or at best will recover with the next
> hotplug-add. The "remove" event beats the "add"! We have the same event
> serializing problem here, we solved with udevd for udev.

I may reactivate my old hotplugd work to address this?

We merge udev and udevd. We parse the config and rules once on startup and
then wait for events as udevd does today.

On a kernel event udevd does a fork() but _no_ exec(). This will create a
new instance of the same code with the already parsed config in memory.

The forked udevd instance will:
  o wait for sysfs internally
  o if needed create the node and set the environment
  o execute /etc/hotplug.d/ scripts (with DEVPATH in the environment)

This leads to:
  o complete serialized hotplug sequence handling
  o hotplug.d/ execution with sane sysfs state and created node
  o no more dev.d/ (can just live in hotplug.d/)
  o no udev disk activity (with nodes and db on tmpfs)
  o only one process fork() for every event (besides possible callouts)

It is a bit far from the current model but we already rely on a running
daemon. I've had something like this in mind with all my recent work.
In the very long run we may even set /proc/sys/kernel/hotplug to "" after
bootup and udevd(hotplugd) can get the hotplug-events over netlink :)

What do you think?

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Greg KH]

On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> > On Fri, Oct 15, 2004 at 08:48:39PM +0200, Kay Sievers wrote:
> > > On Fri, Oct 15, 2004 at 11:34:33AM -0700, Greg KH wrote:
> > > > On Fri, Oct 15, 2004 at 02:23:53AM +0200, Kay Sievers wrote:
> > > > > On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> > > > > > I've some debug output from a patched wait_for_sysfs. But no idea,
> > > > > > what's going wrong here:
> > > > > 
> > > > > Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
> > > > > for the same device. Only the second event will create the "dev" file we're
> > > > > looking for. So the first event will spin until the second arrives with the file.
> > > > 
> > > > Is this with the -mm tree?  or a "clean" 2.6.9-rc4 kernel?
> > > 
> > > It happens with a 2.6.8 kernel.
> > 
> > Ugh.  In looking at the kernel code, I don't see how it could be doing
> > this.  But the console startup code is a strange beast...
> 
> I'm getting closer:
> This is the sequence I get on bootup:
> 
>   SUBSYSTEM=net
>   DEVPATH=/class/net/sit0
>   SEQNUM&0
>   ACTION­d
> 
>   SUBSYSTEM=vc
>   DEVPATH=/class/vc/vcs4
>   SEQNUM&1
>   ACTION­d
> 
>   SUBSYSTEM=vc
>   DEVPATH=/class/vc/vcsa4
>   SEQNUM&2
>   ACTION­d
> 
>   SUBSYSTEM=vc
>   DEVPATH=/class/vc/vcs4
>   SEQNUM&3
>   ACTION=remove
> 
>   SUBSYSTEM=vc
>   DEVPATH=/class/vc/vcsa4
>   SEQNUM&4
>   ACTION=remove
> 
>   SUBSYSTEM=vc
>   DEVPATH=/class/vc/vcs4
>   SEQNUM&5
>   ACTION­d
> 
>   SUBSYSTEM=vc
>   DEVPATH=/class/vc/vcsa4
>   SEQNUM&6
>   ACTION­d
> 
> According to the kernel code the vc is created on open() and destroyed
> on close() which causes hotplug events.  Seems like the bootup opens and
> closes a vc two times for every device.
> The close will remove the "dev" file and the wait_for_sysfs from the
> add-hotplug will spin and fail or at best will recover with the next
> hotplug-add. The "remove" event beats the "add"! We have the same event
> serializing problem here, we solved with udevd for udev.

Heh, no fun.

Ok, I fixed this by watching for the directory to go away from under us.
In my booting I couldn't duplicate these messages anymore...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Greg KH]

On Fri, Oct 15, 2004 at 10:09:25PM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote:
> > On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> > > 
> > > Ugh.  In looking at the kernel code, I don't see how it could be doing
> > > this.  But the console startup code is a strange beast...
> > 
> > The close will remove the "dev" file and the wait_for_sysfs from the
> > add-hotplug will spin and fail or at best will recover with the next
> > hotplug-add. The "remove" event beats the "add"! We have the same event
> > serializing problem here, we solved with udevd for udev.
> 
> I may reactivate my old hotplugd work to address this?
> 
> We merge udev and udevd. We parse the config and rules once on startup and
> then wait for events as udevd does today.
> 
> On a kernel event udevd does a fork() but _no_ exec(). This will create a
> new instance of the same code with the already parsed config in memory.
> 
> The forked udevd instance will:
>   o wait for sysfs internally
>   o if needed create the node and set the environment
>   o execute /etc/hotplug.d/ scripts (with DEVPATH in the environment)
> 
> This leads to:
>   o complete serialized hotplug sequence handling
>   o hotplug.d/ execution with sane sysfs state and created node
>   o no more dev.d/ (can just live in hotplug.d/)
>   o no udev disk activity (with nodes and db on tmpfs)
>   o only one process fork() for every event (besides possible callouts)
> 
> It is a bit far from the current model but we already rely on a running
> daemon. I've had something like this in mind with all my recent work.
> In the very long run we may even set /proc/sys/kernel/hotplug to "" after
> bootup and udevd(hotplugd) can get the hotplug-events over netlink :)
> 
> What do you think?

I think it's a big rewrite from what we have working today :)

Although some of the benifits you list might be nice to have. I don't
know how well we could get rid of the dev.d/ stuff, as we still can't
map hotplug events to dev.d/ events without running through udev (so a
hotplug.d script would know where to be placed.)

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: strange delays in vc class

[Kay Sievers]

On Fri, Oct 15, 2004 at 04:20:01PM -0700, Greg KH wrote:
> On Fri, Oct 15, 2004 at 10:09:25PM +0200, Kay Sievers wrote:
> > On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote:
> > > On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> > > > 
> > > > Ugh.  In looking at the kernel code, I don't see how it could be doing
> > > > this.  But the console startup code is a strange beast...
> > > 
> > > The close will remove the "dev" file and the wait_for_sysfs from the
> > > add-hotplug will spin and fail or at best will recover with the next
> > > hotplug-add. The "remove" event beats the "add"! We have the same event
> > > serializing problem here, we solved with udevd for udev.
> > 
> > I may reactivate my old hotplugd work to address this?
> > 
> > We merge udev and udevd. We parse the config and rules once on startup and
> > then wait for events as udevd does today.
> > 
> > On a kernel event udevd does a fork() but _no_ exec(). This will create a
> > new instance of the same code with the already parsed config in memory.
> > 
> > The forked udevd instance will:
> >   o wait for sysfs internally
> >   o if needed create the node and set the environment
> >   o execute /etc/hotplug.d/ scripts (with DEVPATH in the environment)
> > 
> > This leads to:
> >   o complete serialized hotplug sequence handling
> >   o hotplug.d/ execution with sane sysfs state and created node
> >   o no more dev.d/ (can just live in hotplug.d/)
> >   o no udev disk activity (with nodes and db on tmpfs)
> >   o only one process fork() for every event (besides possible callouts)
> > 
> > It is a bit far from the current model but we already rely on a running
> > daemon. I've had something like this in mind with all my recent work.
> > In the very long run we may even set /proc/sys/kernel/hotplug to "" after
> > bootup and udevd(hotplugd) can get the hotplug-events over netlink :)
> > 
> > What do you think?
> 
> I think it's a big rewrite from what we have working today :)

I would call it a reoganization :)
We have all stuff already working, just in a different way.

> Although some of the benifits you list might be nice to have. I don't
> know how well we could get rid of the dev.d/ stuff, as we still can't
> map hotplug events to dev.d/ events without running through udev (so a
> hotplug.d script would know where to be placed.)

We use the SEQNUM in HAL to do this.  The idea is, that we have only _one_
kind of event and only one directory to handle that. Ther is no longer the
need to map anything.

Let me try to be more clear:

  o We have one daemon listening for kernel events:
      - no other action is taken on a kernel event than let the
        daemon know about it
      - no multiplexer shell script runs

  o The daemon (like current udevd):
      - reorders the events
      - prevents parallel event execution for the same DEVPATH
      - forks one helper per event

  o The helper instance (like current udev):
      - waits for sysfs
      - creates the device node if neccessary and places DEVNAME into
        the environment
      - forks all scripts in hotplug.d/ even when no device node was created

All current dev.d/ scripts can moved to hotplug.d/ and will work as
before. All scripts in hotplug.d/ will have the device node created, the
right sequence order and sysfs fully populated.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel