headers
Greg KH | 1 Apr 2004 01:14
Gravatar

Re: [PATCH] netdev - udevdb+dev.d changes

On Sun, Mar 28, 2004 at 08:48:40PM +0200, Kay Sievers wrote:
> Hey, Chris fixed the udevd hole and Treeve found the timestamp bug,
> so there was nothing left for me at the weekend :)
> 
> Here is a patch to change the netdev handling in the database and for
> the dev.d/ calls. I applies on top of the udevd.patch, cause klibc has
> no sysinfo().

Thanks, I've applied this now.

>  o netdev's are also put into our database now. I want this for the
>    udevruler gui to get a list of all handled devices.
>    All devices in the db are stamped with the system uptime value at
>    the creation time. 'udevinfo -d' prints it.

nice.

>  o the DEVPATH value is the key for udevdb, but if we rename
>    a netdev, the name is replaced in the kernel, so we add
>    the changed name to the db to match with the remove event.
>    
>    NOTE: The dev.d/ scripts still get the original name from the
>    hotplug call. Should we replace DEVPATH with the new name too?

Yeah, we should.

>  o We now only add a device to the db, if we have successfully created
>    the main node or successfully renamed a netdev. This is the main part
>    of the patch, cause I needed to clean the retval passing trough all
>    the functions used for node creation.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Greg KH | 1 Apr 2004 01:04
Gravatar

Re: [PATCH[ udevd race conditions and performance, assorted cleanups

On Sun, Mar 28, 2004 at 03:08:45AM +0200, Kay Sievers wrote:
> here is a patch on top of your nice improvements.
> I fixed the whitespace and it hopefully fixes the stupid timestamp bug in
> udevd. Some stupid OS sets the hwclock to localtime and linux changes it
> to UTC while starting. If any events are pending they may be delayed by
> the users time distance from UTC :) So we use the uptime seconds now.

Nice fix, applied.

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Permalink | Reply | 0 comments |
headers
Greg KH | 1 Apr 2004 01:00
Gravatar

Re: udevinfo patch

On Fri, Mar 26, 2004 at 06:19:47PM +0100, Kay Sievers wrote:
> On Fri, Mar 26, 2004 at 06:36:32PM +0500, Ananth N Mavinakayanahalli wrote:
> > On Fri, Mar 26, 2004 at 11:24:39AM +0100, Kay Sievers wrote:
> > > On Fri, Mar 26, 2004 at 11:21:29AM +0500, Ananth N Mavinakayanahalli wrote:
> > > > On Fri, Mar 26, 2004 at 04:47:35AM +0100, Kay Sievers wrote:
> > > > > On Fri, Mar 26, 2004 at 01:26:46AM +0100, Carl-Daniel Hailfinger wrote:
> > > > > > Greg KH wrote:
> > > > > > > On Tue, Mar 23, 2004 at 01:51:01PM -0800, Daniel Stekloff wrote:
> > > > > 
> > > > > No, it breaks the net device handling. I think we should change
> > > > > libsysfs instead, not to return a class device for '/block', if
> > > > > we want to fix it.
> > > > 
> > > > /sys/block is considered a sysfs "class" and not a class_device. So, 
> > > > going by udevinfo's help, -p expects path to a class_device and _not_ 
> > > > a class itself and hence option /sys/block with -p is not a valid query. 
> > > > 
> > > > Kay?
> > > 
> > > Yes, it's invalid, but we shouldn't print major minor for a invalid
> > > path. sysfs_open_class_device_path("/block") returns a device. If this is
> > > the right behavior for libsysfs, I will change the get_device_type("/block")
> > > not to return a 'b'-type.
> > 
> > Libsysfs validates the path given to it for opening a class_device to be
> > a valid directory; it does not however validate if the path is a valid
> > class_device path. So, in the case of udevinfo, a 'b' type should not 
> > be returned if the path is just /sys/block or /sys/block/
> 
> This may prevent it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 Apr 2004 01:04
Gravatar

Re: [PATCH[ udevd race conditions and performance, assorted cleanups

On Fri, Mar 26, 2004 at 11:48:15PM -0500, Chris Friesen wrote:
> 
> This patch covers a number of areas:
> 
> 1) sysfs.h is fixed up to use the common dbg() macro.  This fixes the 
> case where DEBUG is defined but USE_LOG isn't.
> 
> 2) udevstart.c is modified to include the proper headers, rather than 
> getting them indirectly which can break depending on Makefile flags
> 
> 3) udevd.c gets some major changes:
> a) I added a pipe from the signal handler.  This fixes the race 
> conditions that I mentioned earlier.  Basically, the point of the pipe 
> is to force the select() call to return immediately if a signal handler 
> fired before we actually started the select() call.  This then lets us 
> run the appropriate code based on flags set in the signal handler proper.
> b) I added a number of flags to coalesce calls to common routines.  This 
> should make things slightly more efficient.
> c) since most calls will tend to come in with a sequence number larger 
> than what has been received, I switched msg_queue_insert() to scan the 
> msg_list backwards to improve performance.
> 
> Comments?

Thanks for doing this, applied.

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kay Sievers | 1 Apr 2004 01:40

Re: [PATCH] netdev - udevdb+dev.d changes

On Wed, Mar 31, 2004 at 03:14:10PM -0800, Greg KH wrote:
> On Sun, Mar 28, 2004 at 08:48:40PM +0200, Kay Sievers wrote:
> >  o the DEVPATH value is the key for udevdb, but if we rename
> >    a netdev, the name is replaced in the kernel, so we add
> >    the changed name to the db to match with the remove event.
> >    
> >    NOTE: The dev.d/ scripts still get the original name from the
> >    hotplug call. Should we replace DEVPATH with the new name too?
> 
> Yeah, we should.

Ok, I will prepare a patch, now.

> >  o We now only add a device to the db, if we have successfully created
> >    the main node or successfully renamed a netdev. This is the main part
> >    of the patch, cause I needed to clean the retval passing trough all
> >    the functions used for node creation.
> > 
> >  o DEVNODE sounds a bit ugly for netdev's so I exported DEVNAME too.
> >    Can we change the name?
> 
> Can you think of a better name?

I think DEVNAME sounds better for a netdev and is fine for a node too?
What do you think?

thanks,
Kay

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg KH | 1 Apr 2004 02:22
Gravatar

Re: [PATCH] netdev - udevdb+dev.d changes

On Thu, Apr 01, 2004 at 01:40:26AM +0200, Kay Sievers wrote:
> > >  o We now only add a device to the db, if we have successfully created
> > >    the main node or successfully renamed a netdev. This is the main part
> > >    of the patch, cause I needed to clean the retval passing trough all
> > >    the functions used for node creation.
> > > 
> > >  o DEVNODE sounds a bit ugly for netdev's so I exported DEVNAME too.
> > >    Can we change the name?
> > 
> > Can you think of a better name?
> 
> I think DEVNAME sounds better for a netdev and is fine for a node too?
> What do you think?

That's what I originally had, yet changed it to DEVNODE.  But now that
we have network device support, it makes more sense to call it that.
Care to make a patch that does that too?

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Permalink | Reply | 2 comments |
headers
Kay Sievers | 1 Apr 2004 02:41

Re: [PATCH] netdev - udevdb+dev.d changes

On Wed, Mar 31, 2004 at 04:22:30PM -0800, Greg KH wrote:
> On Thu, Apr 01, 2004 at 01:40:26AM +0200, Kay Sievers wrote:
> > > >  o We now only add a device to the db, if we have successfully created
> > > >    the main node or successfully renamed a netdev. This is the main part
> > > >    of the patch, cause I needed to clean the retval passing trough all
> > > >    the functions used for node creation.
> > > > 
> > > >  o DEVNODE sounds a bit ugly for netdev's so I exported DEVNAME too.
> > > >    Can we change the name?
> > > 
> > > Can you think of a better name?
> > 
> > I think DEVNAME sounds better for a netdev and is fine for a node too?
> > What do you think?
> 
> That's what I originally had, yet changed it to DEVNODE.  But now that
> we have network device support, it makes more sense to call it that.
> Care to make a patch that does that too?

Here we change the DEVPATH for netdev's in the environment of the dev.d/
scripts to the name the device is renamed to. The original name doesn't
exist in the kernel after rename.

Do you have anything already done for the man page for the new dev.d/
logic? If not, I will care.

thanks,
Kay

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Greg KH
 | 
1 Apr 2004 03:02






Gravatar





Re: [PATCH] netdev - udevdb+dev.d changes


On Thu, Apr 01, 2004 at 02:41:29AM +0200, Kay Sievers wrote:
> 
> Here we change the DEVPATH for netdev's in the environment of the dev.d/
> scripts to the name the device is renamed to. The original name doesn't
> exist in the kernel after rename.

Thanks, I've applied this.

> Do you have anything already done for the man page for the new dev.d/
> logic? If not, I will care.

No, I only wrote it up in the RFC-dev.d file in the docs directory.

Hm, that needs to be changed now due to this patch, I'll go do that
right now...

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Kay Sievers
 | 
1 Apr 2004 03:07





timeout udevd too hort


Bahh, I thought we introduced a bug in udevd with the recent changes,
but it seems I have a really slow device here.

We currently have a event timeout of 5 seconds to wait for a missing
event. I can catch it by activating my Thinkpad's builtin bluetooth
hardware. Sometimes the kernel needs 6 seconds to submit all the
hotplug events for this device.
Should we increase it to 10 seconds?

thanks,
Kay

device:
  Bus 001 Device 004: ID 0aec:3260 Neodio Technologies Corp.

udevdsend log:
  Apr  1 02:54:08 pim udevsend[12119]: main: version 023_bk
  Apr  1 02:54:08 pim udevsend[12119]: main: subsystem = 'tty'
  Apr  1 02:54:08 pim udevsend[12119]: main: DEVPATH = '/class/tty/ttyUB0'
  Apr  1 02:54:08 pim udevsend[12119]: main: ACTION = 'remove'
  Apr  1 02:54:08 pim udevsend[12119]: main: SEQNUM = '340'
  Apr  1 02:54:08 pim udevsend[12120]: main: version 023_bk
  Apr  1 02:54:08 pim udevsend[12120]: main: subsystem = 'usb'
  Apr  1 02:54:08 pim udevsend[12120]: main: DEVPATH = '/devices/pci0000:00/0000:00:1d.2/usb4/4-1'
  Apr  1 02:54:08 pim udevsend[12120]: main: ACTION = 'remove'
  Apr  1 02:54:08 pim udevsend[12120]: main: SEQNUM = '344'
  Apr  1 02:54:09 pim udevsend[12133]: main: version 023_bk
  Apr  1 02:54:09 pim udevsend[12133]: main: subsystem = 'usb'
  Apr  1 02:54:09 pim udevsend[12133]: main: DEVPATH = '/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.1'
  Apr  1 02:54:09 pim udevsend[12133]: main: ACTION = 'remove'

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Greg KH
 | 
1 Apr 2004 08:40






Gravatar





Re: timeout udevd too hort


On Thu, Apr 01, 2004 at 03:07:26AM +0200, Kay Sievers wrote:
> Bahh, I thought we introduced a bug in udevd with the recent changes,
> but it seems I have a really slow device here.
> 
> We currently have a event timeout of 5 seconds to wait for a missing
> event. I can catch it by activating my Thinkpad's builtin bluetooth
> hardware. Sometimes the kernel needs 6 seconds to submit all the
> hotplug events for this device.

Ouch, that log trail was pretty bad.  It's nice to see we can duplicate
out-of-order messages :)

> Should we increase it to 10 seconds?

I don't have a problem with doing that.  Anyone else?

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane