* Re: [PATCH] Export SMBIOS provided firmware instance and label to
From: Greg KH @ 2010-07-21 3:54 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE612BD1@blrx3m08.blr.amer.dell.com>
On Mon, Jul 19, 2010 at 10:24:39PM +0530, Narendra_K@Dell.com wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Narendra K
> > Sent: Wednesday, July 14, 2010 5:44 PM
> > To: greg@kroah.com
> > Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> > pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> > Nijhawan, Vijay
> > Subject: Re: [PATCH] Export SMBIOS provided firmware instance and
> label
> > to sysfs
> >
> >
> > V1 -> V2:
> >
> > 1. The 'smbios_attr' buffer is not being used as mentioned above
> >
> > 2. The function 'smbios_instance_string_exist' is split into two
> > functions,
> > the other being 'find_smbios_instance_string' which would print the
> > result
> > into the sysfs provided 'buf' of associated device. The function
> > 'smbios_instance_string_exist' would let us know if the label exists
> or
> > not.
> >
> > Please find the patch with above changes here -
> >
> > From: Narendra K <narendra_k@dell.com>
> > Subject: [PATCH] Export SMBIOS provided firmware instance and label to
> > sysfs
> >
>
> Greg,
>
> Thanks for the review comments.
>
> This version of the patch has all the suggestions incorporated. Please
> let us know if there are any concerns. If the approach is acceptable,
> please consider this patch for inclusion.
What "version"? The previous one you sent? I'll look at it, but note
that I'm not the maintainer who you need to convince to accept it :)
thanks,
greg k-h
^ permalink raw reply
* Re: What variables are important when a cdrom is in or out?
From: Stef Bon @ 2010-07-20 22:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTilWvuVVCWFvw33OjfmFhqGeazobCqIRoQp-Mgee@mail.gmail.com>
2010/7/21 Kay Sievers <kay.sievers@vrfy.org>:
> On Tue, Jul 20, 2010 at 23:36, Stef Bon <stefbon@gmail.com> wrote:
>>
>> I see the variables ID_FS_*** are set. I can make my scripts look at
>> these to determine the cdrom is in or out.
>> Is this ok? Or do I have to check the  parameter ID_CDROM_MEDIA=1? Or
>> something else?
>
> It's ID_CDROM_MEDIA=1 for any media.
>
> If you want to access the raw disk, you want
> ID_CDROM_MEDIA_TRACK_COUNT_DATA=?*, because real CD Audio CDs must not
> be accessed like a filesystem, or probed for one.
>
> ID_FS_* might not be set, if there is an unknown data format on it.
So, it's the parameter ID_CDROM_MEDIA. That's simple. Thanks a lot!
Futher, if there is an filesystem which is reckognized, the ID_FS_*
parameters are set.
I've inserted a audio cd, and indeed I get the
ID_CDROM_MEDIA_TRACK_COUNT equal to 18,
and ID_CDROM_MEDIA_TRACK_COUNT_AUDIO also 18. Does this mean that
there is also an
ID_CDROM_MEDIA_TRACK_COUNT_VIDEO??
And what's the meaning of the ID_CDROM_MEDIA_SESSION_COUNT? Multisession cd's?
Stef
^ permalink raw reply
* Re: What variables are important when a cdrom is in or out?
From: Kay Sievers @ 2010-07-20 22:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTilWvuVVCWFvw33OjfmFhqGeazobCqIRoQp-Mgee@mail.gmail.com>
On Tue, Jul 20, 2010 at 23:36, Stef Bon <stefbon@gmail.com> wrote:
> I would like to know what variable is THE variable to point a cdrom is
> in the drive or not.
>
> I've made a udev rule to output all the variables set when a media change.
>
> Now look when a drive is ejected. The output:
>
> ID_BUS=scsi
> ID_CDROM=1
> ID_CDROM_CD=1
> ID_CDROM_CD_R=1
> ID_CDROM_CD_RW=1
> ID_CDROM_DVD=1
> ID_CDROM_DVD_PLUS_R=1
> ID_CDROM_DVD_PLUS_RW=1
> ID_CDROM_DVD_PLUS_R_DL=1
> ID_CDROM_DVD_R=1
> ID_CDROM_DVD_RAM=1
> ID_CDROM_DVD_RW=1
> ID_CDROM_MRW=1
> ID_CDROM_MRW_W=1
> ID_MODEL=DVD_RW_AD-7170S
> ID_MODEL_ENC='DVD\x20RW\x20AD-7170S\x20'
> ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
> ID_REVISION=1.00
> ID_SCSI=1
> ID_TYPEÍ
> ID_VENDOR=Optiarc
> ID_VENDOR_ENC='Optiarc\x20'
>
> When it's inserted again:
>
>
> ID_BUS=scsi
> ID_CDROM=1
> ID_CDROM_CD=1
> ID_CDROM_CD_R=1
> ID_CDROM_CD_RW=1
> ID_CDROM_DVD=1
> ID_CDROM_DVD_PLUS_R=1
> ID_CDROM_DVD_PLUS_RW=1
> ID_CDROM_DVD_PLUS_R_DL=1
> ID_CDROM_DVD_R=1
> ID_CDROM_DVD_RAM=1
> ID_CDROM_DVD_RW=1
> ID_CDROM_MEDIA=1
> ID_CDROM_MEDIA_CD_R=1
> ID_CDROM_MEDIA_SESSION_COUNT=1
> ID_CDROM_MEDIA_STATE=complete
> ID_CDROM_MEDIA_TRACK_COUNT=1
> ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
> ID_CDROM_MRW=1
> ID_CDROM_MRW_W=1
> ID_FS_LABEL=openSUSE-NET-i586-Build0475..001
> ID_FS_LABEL_ENC=openSUSE-NET-i586-Build0475..001
> ID_FS_TYPE=iso9660
> ID_FS_USAGE=filesystem
> ID_MODEL=DVD_RW_AD-7170S
> ID_MODEL_ENC='DVD\x20RW\x20AD-7170S\x20'
> ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
> ID_REVISION=1.00
> ID_SCSI=1
> ID_TYPEÍ
> ID_VENDOR=Optiarc
> ID_VENDOR_ENC='Optiarc\x20'
>
>
> I see the variables ID_FS_*** are set. I can make my scripts look at
> these to determine the cdrom is in or out.
> Is this ok? Or do I have to check the  parameter ID_CDROM_MEDIA=1? Or
> something else?
It's ID_CDROM_MEDIA=1 for any media.
If you want to access the raw disk, you want
ID_CDROM_MEDIA_TRACK_COUNT_DATA=?*, because real CD Audio CDs must not
be accessed like a filesystem, or probed for one.
ID_FS_* might not be set, if there is an unknown data format on it.
Kay
^ permalink raw reply
* What variables are important when a cdrom is in or out?
From: Stef Bon @ 2010-07-20 21:36 UTC (permalink / raw)
To: linux-hotplug
Hello,
I would like to know what variable is THE variable to point a cdrom is
in the drive or not.
I've made a udev rule to output all the variables set when a media change.
Now look when a drive is ejected. The output:
ID_BUS=scsi
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_RW=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_MODEL=DVD_RW_AD-7170S
ID_MODEL_ENC='DVD\x20RW\x20AD-7170S\x20'
ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
ID_REVISION=1.00
ID_SCSI=1
ID_TYPEÍ
ID_VENDOR=Optiarc
ID_VENDOR_ENC='Optiarc\x20'
When it's inserted again:
ID_BUS=scsi
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_RW=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD_R=1
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_STATE=complete
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_FS_LABEL=openSUSE-NET-i586-Build0475..001
ID_FS_LABEL_ENC=openSUSE-NET-i586-Build0475..001
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
ID_MODEL=DVD_RW_AD-7170S
ID_MODEL_ENC='DVD\x20RW\x20AD-7170S\x20'
ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
ID_REVISION=1.00
ID_SCSI=1
ID_TYPEÍ
ID_VENDOR=Optiarc
ID_VENDOR_ENC='Optiarc\x20'
I see the variables ID_FS_*** are set. I can make my scripts look at
these to determine the cdrom is in or out.
Is this ok? Or do I have to check the parameter ID_CDROM_MEDIA=1? Or
something else?
Stef Bon
^ permalink raw reply
* RE: FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-20 17:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
>
> -> That is the issue. There appears to be no notification .
>
> >> For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ?
>
> When a ethX device is reported as created by the kernel.
>
> -> On RH (5.5), 60-net.rules never get invoked on boot for a ethernet adapter.
Then file a bug with Red Hat about this, not much we can do about it here, right?
good luck,
--> Thanks ! That is what I am trying to identify.
^ permalink raw reply
* Re: FW: udev documentation
From: Greg KH @ 2010-07-20 17:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
On Mon, Jul 19, 2010 at 06:51:19PM +0000, Donnelly, John (ISS (SNI), Houston) wrote:
>
> And when you remove an ethernet device, the kernel removes the ethX device, and any userspace mappings you had you need to then clean up as well on your own.
>
> -> That is the issue. There appears to be no notification .
>
> >> For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ?
>
> When a ethX device is reported as created by the kernel.
>
> -> On RH (5.5), 60-net.rules never get invoked on boot for a ethernet adapter.
Then file a bug with Red Hat about this, not much we can do about it
here, right?
good luck,
greg k-h
^ permalink raw reply
* Re: Detecting USB over-current
From: Kay Sievers @ 2010-07-20 14:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikpAwn_ggCiXidPc-aqrbaZ-X584VofiPoTyB0Z@mail.gmail.com>
On Tue, Jul 20, 2010 at 15:11, Jim Paris <jim@jtan.com> wrote:
> Kay Sievers wrote:
>> On Mon, Jul 19, 2010 at 23:47, Luis Felipe Strano Moraes
>> <luis.strano@gmail.com> wrote:
>> > I've been searching if it's possible to receive an event on udev regarding
>> > over-current on a USB port, but so far have been unable to find anything.
>> >
>> > Does anyone have any ideas about how I can do this?
>>
>> Udev does not provide anything like this, and is unlikely the right
>> place to add support for things like this.
>>
>> Better ask at the linux-usb list if you can somehow watch devices for
>> this state.
>
> There was some relatively recent discussion about this on linux-usb here:
> Â http://thread.gmane.org/gmane.linux.usb.general/27802/focus'991
Yeah, that happens quite often, but for many reasons it's totally
wrong to use uevents for error reporting or anything not related to
very basic device state changes, just because nobody provides any
appropriate infrastructure to get errors from the kernel to userspace.
:)
Kay
^ permalink raw reply
* Re: Detecting USB over-current
From: Jim Paris @ 2010-07-20 13:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikpAwn_ggCiXidPc-aqrbaZ-X584VofiPoTyB0Z@mail.gmail.com>
Kay Sievers wrote:
> On Mon, Jul 19, 2010 at 23:47, Luis Felipe Strano Moraes
> <luis.strano@gmail.com> wrote:
> > I've been searching if it's possible to receive an event on udev regarding
> > over-current on a USB port, but so far have been unable to find anything.
> >
> > Does anyone have any ideas about how I can do this?
>
> Udev does not provide anything like this, and is unlikely the right
> place to add support for things like this.
>
> Better ask at the linux-usb list if you can somehow watch devices for
> this state.
There was some relatively recent discussion about this on linux-usb here:
http://thread.gmane.org/gmane.linux.usb.general/27802/focus'991
-jim
^ permalink raw reply
* Re: Detecting USB over-current
From: Kay Sievers @ 2010-07-20 7:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikpAwn_ggCiXidPc-aqrbaZ-X584VofiPoTyB0Z@mail.gmail.com>
On Mon, Jul 19, 2010 at 23:47, Luis Felipe Strano Moraes
<luis.strano@gmail.com> wrote:
> I've been searching if it's possible to receive an event on udev regarding
> over-current on a USB port, but so far have been unable to find anything.
>
> Does anyone have any ideas about how I can do this?
Udev does not provide anything like this, and is unlikely the right
place to add support for things like this.
Better ask at the linux-usb list if you can somehow watch devices for
this state.
Kay
^ permalink raw reply
* Detecting USB over-current
From: Luis Felipe Strano Moraes @ 2010-07-19 21:47 UTC (permalink / raw)
To: linux-hotplug
Hello,
I've been searching if it's possible to receive an event on udev regarding
over-current on a USB port, but so far have been unable to find anything.
Does anyone have any ideas about how I can do this?
Best regards,
--lf
--
"I believe in looking reality straight in the eye and denying it." --
Garrison Keillor
^ permalink raw reply
* RE: FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-19 18:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
And when you remove an ethernet device, the kernel removes the ethX device, and any userspace mappings you had you need to then clean up as well on your own.
-> That is the issue. There appears to be no notification .
>> For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ?
When a ethX device is reported as created by the kernel.
-> On RH (5.5), 60-net.rules never get invoked on boot for a ethernet adapter.
^ permalink raw reply
* RE: [PATCH] Export SMBIOS provided firmware instance and label to sysfs
From: Narendra_K @ 2010-07-19 16:57 UTC (permalink / raw)
To: Narendra_K, greg
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20100714121345.GA20411@auslistsprd01.us.dell.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Narendra K
> Sent: Wednesday, July 14, 2010 5:44 PM
> To: greg@kroah.com
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> Nijhawan, Vijay
> Subject: Re: [PATCH] Export SMBIOS provided firmware instance and
label
> to sysfs
>
>
> V1 -> V2:
>
> 1. The 'smbios_attr' buffer is not being used as mentioned above
>
> 2. The function 'smbios_instance_string_exist' is split into two
> functions,
> the other being 'find_smbios_instance_string' which would print the
> result
> into the sysfs provided 'buf' of associated device. The function
> 'smbios_instance_string_exist' would let us know if the label exists
or
> not.
>
> Please find the patch with above changes here -
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Export SMBIOS provided firmware instance and label to
> sysfs
>
Greg,
Thanks for the review comments.
This version of the patch has all the suggestions incorporated. Please
let us know if there are any concerns. If the approach is acceptable,
please consider this patch for inclusion.
With regards,
Narendra K
^ permalink raw reply
* RE: FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-16 15:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
>
> >What are you looking to have udev do? What is the problem you are having?
>
> Using static MAC's within a system creates config conflicts when
> adapters are exchanged that have different PCI-ID and drivers. Often
> the reconfigured machine will not boot (because of modprobe entries )
> or network (ifcfg-ethX ) bring up fails because of stale configuration
> data left behind by the s-c-n tools.
Then don't do that :)
-> It is the infrastructure ... and it's not unique among Enterprise systems.
Wait, what is "s-c-n" tools?
-> system-config-network, aka .. NEAT.
> I am seeking to understand how make a more dynamic ETHERNET
> configuration manager (and underlying components) that bonds PCI-IDs
> and drivers to a ETHERNET device better than they currently do.
The in-kernel driver does this type of "bonding". You mean you want to change your ethernet device naming to be more flexible, right?
> When I remove/replace an adapter with a different one I want to invoke
> udev to clean up stale ethX and modprobe references.
And when you remove an ethernet device, the kernel removes the ethX device, and any userspace mappings you had you need to then clean up as well on your own.
-> That is the issue. There appears to be no notification .
>> For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ?
When a ethX device is reported as created by the kernel.
-> On RH (5.5), 60-net.rules never get invoked on boot for a ethernet adapter.
^ permalink raw reply
* Re: [PATCH] Fix volume keys not releasing on Mivvy G310
From: Martin Pitt @ 2010-07-16 4:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1279249284.1664.53.camel@laptop>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
Hello Jerone,
Jerone Young [2010-07-15 22:01 -0500]:
> Fixes volume keys not senidng key release on My Mivvy G310 laptop.
Thanks! Pushed with some minor wording changes.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Fix volume keys not releasing on Mivvy G310
From: Jerone Young @ 2010-07-16 3:01 UTC (permalink / raw)
To: linux-hotplug
Fixes volume keys not senidng key release on My Mivvy G310 laptop.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keyboard-force-release.rules b/extras/keymap/95-keyboard-force-release.rules
index db8a3b3..cb1fe78 100644
--- a/extras/keymap/95-keyboard-force-release.rules
+++ b/extras/keymap/95-keyboard-force-release.rules
@@ -33,4 +33,6 @@ ENV{DMI_VENDOR}="PEGATRON CORP.", ATTR{[dmi/id]product_name}="Spring Peak", RU
ENV{DMI_VENDOR}="TOSHIBA", ATTR{[dmi/id]product_name}="Satellite U300|Satellite Pro U300|Satellite U305", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+ENV{DMI_VENDOR}="Viooo Corporation", ATTR{[dmi/id]product_name}="PT17", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+
LABEL="force_release_end"
^ permalink raw reply related
* Re: FW: udev documentation
From: Greg KH @ 2010-07-15 16:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
On Thu, Jul 15, 2010 at 03:53:11PM +0000, Donnelly, John (ISS (SNI), Houston) wrote:
>
> >> There are 60-net.rules under /etc/udev ... Are ethernet devices a separate category ?
>
> >No.
>
> >What are you looking to have udev do? What is the problem you are having?
>
> Using static MAC's within a system creates config conflicts when
> adapters are exchanged that have different PCI-ID and drivers. Often
> the reconfigured machine will not boot (because of modprobe entries )
> or network (ifcfg-ethX ) bring up fails because of stale configuration
> data left behind by the s-c-n tools.
Then don't do that :)
Wait, what is "s-c-n" tools?
> I am seeking to understand how make a more dynamic ETHERNET
> configuration manager (and underlying components) that bonds PCI-IDs
> and drivers to a ETHERNET device better than they currently do.
The in-kernel driver does this type of "bonding". You mean you want to
change your ethernet device naming to be more flexible, right?
> When I remove/replace an adapter with a different one I want to invoke
> udev to clean up stale ethX and modprobe references.
What do you mean by "modprobe references"? The kernel will auto-load
drivers when it finds a device that it needs a driver for, right?
And when you remove an ethernet device, the kernel removes the ethX
device, and any userspace mappings you had you need to then clean up as
well on your own.
> For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ?
When a ethX device is reported as created by the kernel.
> My impression now is a driver of the "net" class has to post a message
> to udev to get processed by udevd, which rules a script/program.
Yes, but the core kernel logic does the "message send" here, and udevd
handles it automatically.
hope this helps,
greg k-h
^ permalink raw reply
* Re: FW: udev documentation
From: Kay Sievers @ 2010-07-15 16:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
On Thu, Jul 15, 2010 at 17:53, Donnelly, John (ISS (SNI), Houston)
<john.donnelly@hp.com> wrote:
>
>>> There are 60-net.rules under /etc/udev ... Are ethernet devices a separate category ?
>
>>No.
>
>>What are you looking to have udev do? What is the problem you are having?
>
> Using static MAC's within a system creates config conflicts when adapters are exchanged
> that have different PCI-ID and drivers. Often the reconfigured machine will not boot
> (because of modprobe entries ) or network (ifcfg-ethX ) bring up fails because
> of stale configuration data left behind by the s-c-n tools.
>
> I am seeking to understand how make a more dynamic ETHERNET configuration manager (and underlying components) that bonds PCI-IDs and drivers to a ETHERNET device better than they currently do. When I remove/replace an adapter
> with a different one I want to invoke udev to clean up stale ethX and modprobe references.
>
> For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ? My impression now
> is a driver of the "net" class has to post a message to udev to get processed by udevd,
> which rules a script/program.
>
> Is that correct ?
The kernel creates the device (all the stuff that is in
/sys/devices/), udevd receives the message over netlink (like for all
other devices too).
Udevd matches the rules against the received event, and executes the
specified instructions.
/etc/udev/rules.d/60-net.rules is something a specific distro added,
and not part of udev. All that stuff is different on every single
distro.
Kay
^ permalink raw reply
* RE: FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-15 15:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
>> There are 60-net.rules under /etc/udev ... Are ethernet devices a separate category ?
>No.
>What are you looking to have udev do? What is the problem you are having?
Using static MAC's within a system creates config conflicts when adapters are exchanged
that have different PCI-ID and drivers. Often the reconfigured machine will not boot
(because of modprobe entries ) or network (ifcfg-ethX ) bring up fails because
of stale configuration data left behind by the s-c-n tools.
I am seeking to understand how make a more dynamic ETHERNET configuration manager (and underlying components) that bonds PCI-IDs and drivers to a ETHERNET device better than they currently do. When I remove/replace an adapter
with a different one I want to invoke udev to clean up stale ethX and modprobe references.
For instance .. how does /etc/udev/rules.d/60-net.rules get invoked ? My impression now
is a driver of the "net" class has to post a message to udev to get processed by udevd,
which rules a script/program.
Is that correct ?
> confused,
Mine comes and goes.
^ permalink raw reply
* RE: FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-15 15:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
-----Original Message-----
From: Kay Sievers [mailto:kay.sievers@vrfy.org]
> >What are you looking to have udev do? What is the problem you are
> >having?
> That's distro specific too, and not part of udev.
> Udev has a script and a dynamically updated rule for persistent network interface naming. That's all.
>Udev has no idea what a network interface is, or how to manage any network interface.
>There is no config from udev to apply, besides the possible renaming of the interface before
> userspace is notified about the newly added device.
I'm tracing udevd in "debug" mode and I see no invocation of /etc/udev/<>/60-net.rules.d on boot.
I am considering a ethernet device a "network" subsystem . What subtle point am I missing ?
^ permalink raw reply
* Re: FW: udev documentation
From: Kay Sievers @ 2010-07-15 14:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
On Thu, Jul 15, 2010 at 16:22, Greg KH <greg@kroah.com> wrote:
> On Thu, Jul 15, 2010 at 02:10:35PM +0000, Donnelly, John (ISS (SNI), Houston) wrote:
>> I don't see any interaction by udevd on behave of ethernet adapters during boot
>> after an adapter and driver RPM are added. Generally, the RPM install phase
>> modifies /etc/modprobe.conf .
>
> That's up to rpm scripts, and has nothing to do with udev, right?
>
>> It appears that NEAT (system-config-network) and NetManager create the
>> /etc/system/networking/ifcfg-ethX files.
>
> Ok, but that's a distro thing, right?
>
>> There are 60-net.rules under /etc/udev ... Are ethernet devices a separate category ?
>
> No.
>
> What are you looking to have udev do? Â What is the problem you are
> having?
That's distro specific too, and not part of udev.
Udev has a script and a dynamically updated rule for persistent
network interface naming. That's all.
Udev has no idea what a network interface is, or how to manage any
network interface. There is no config from udev to apply, besides the
possible renaming of the interface before userspace is notified about
the newly added device.
All further network specific properties are not managed by udev.
Kay
^ permalink raw reply
* Re: FW: udev documentation
From: Greg KH @ 2010-07-15 14:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
On Thu, Jul 15, 2010 at 02:10:35PM +0000, Donnelly, John (ISS (SNI), Houston) wrote:
>
> Hi,
>
> I don't see any interaction by udevd on behave of ethernet adapters during boot
> after an adapter and driver RPM are added. Generally, the RPM install phase
> modifies /etc/modprobe.conf .
That's up to rpm scripts, and has nothing to do with udev, right?
> It appears that NEAT (system-config-network) and NetManager create the
> /etc/system/networking/ifcfg-ethX files.
Ok, but that's a distro thing, right?
> There are 60-net.rules under /etc/udev ... Are ethernet devices a separate category ?
No.
What are you looking to have udev do? What is the problem you are
having?
confused,
greg k-h
^ permalink raw reply
* RE: FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-15 14:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
Hi,
I don't see any interaction by udevd on behave of ethernet adapters during boot
after an adapter and driver RPM are added. Generally, the RPM install phase
modifies /etc/modprobe.conf .
It appears that NEAT (system-config-network) and NetManager create the
/etc/system/networking/ifcfg-ethX files.
There are 60-net.rules under /etc/udev ... Are ethernet devices a separate category ?
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Wednesday, July 14, 2010 11:22 PM
To: Donnelly, John (ISS (SNI), Houston)
Cc: linux-hotplug@vger.kernel.org
Subject: Re: FW: udev documentation
On Wed, Jul 14, 2010 at 10:34:35PM +0000, Donnelly, John (ISS (SNI), Houston) wrote:
> I am investigating how to create a class of Ethernet devices to be
> managed under udev
What do you mean "managed under udev"? Right now udev can handle renaming network devices, and ethtool is used for all sorts of other configuration options of ethernet devices. What is currently missing?
> Is there more documentation other than the man pages for udev ? I
> checked the kernel/Documentation too.
What are you trying to do that didn't work out that the documentation is not covering?
thanks,
greg k-h
^ permalink raw reply
* Re: FW: udev documentation
From: Greg KH @ 2010-07-15 4:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A9809FE53BED6C4489428F7DEE02C3FC647B232906@GVW1095EXB.americas.hpqcorp.net>
On Wed, Jul 14, 2010 at 10:34:35PM +0000, Donnelly, John (ISS (SNI), Houston) wrote:
> I am investigating how to create a class of Ethernet devices to be
> managed under udev
What do you mean "managed under udev"? Right now udev can handle
renaming network devices, and ethtool is used for all sorts of other
configuration options of ethernet devices. What is currently missing?
> Is there more documentation other than the man pages for udev ? I
> checked the kernel/Documentation too.
What are you trying to do that didn't work out that the documentation is
not covering?
thanks,
greg k-h
^ permalink raw reply
* FW: udev documentation
From: Donnelly, John (ISS (SNI), Houston) @ 2010-07-14 22:34 UTC (permalink / raw)
To: linux-hotplug
Hello folks.
I am investigating how to create a class of Ethernet devices to be managed under udev
Is there more documentation other than the man pages for udev ? I checked the kernel/Documentation too.
^ permalink raw reply
* Re: [PATCH] Export SMBIOS provided firmware instance and label to sysfs
From: Narendra K @ 2010-07-14 12:13 UTC (permalink / raw)
To: greg
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, charles_rose,
jordan_hargrave, vijay_nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE612B93@blrx3m08.blr.amer.dell.com>
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Saturday, July 10, 2010 11:22 PM
> To: K, Narendra
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org;
> linux-pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave,
> Jordan; Nijhawan, Vijay
> Subject: Re: [PATCH] Export SMBIOS provided firmware instance and label
> to sysfs
>
> On Sat, Jul 10, 2010 at 12:14:45PM -0500, Narendra K wrote:
> > +static char smbios_attr[4096];
> > +
> > +enum smbios_attr_enum {
> > + SMBIOS_ATTR_LABEL_SHOW = 1,
> > + SMBIOS_ATTR_INSTANCE_SHOW,
> donboard->instance);
> > + else if (attribute = SMBIOS_ATTR_LABEL_SHOW)
> > + return scnprintf(smbios_attr, PAGE_SIZE,
> > + "%s\n", dmi->name);
>
> Wait, depending on the attribute you are looking at, you are placing the
> data in a single buffer? What happens if userspace opens and reads both
> files at once?
>
Yes. Also, the scenario of "label" of two pci devices being read by
userapce once will not be handled properly with this approach.
> Please don't use this function for your show attributes, just properly
> copy the correct string into the userspace buffer. This logic just
> complicates things a lot more, right?
V1 -> V2:
1. The 'smbios_attr' buffer is not being used as mentioned above
2. The function 'smbios_instance_string_exist' is split into two functions,
the other being 'find_smbios_instance_string' which would print the result
into the sysfs provided 'buf' of associated device. The function
'smbios_instance_string_exist' would let us know if the label exists or not.
Please find the patch with above changes here -
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Export SMBIOS provided firmware instance and label to sysfs
This patch exports SMBIOS provided firmware instance and label
of onboard pci devices to sysfs
Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
Signed-off-by: Narendra K <narendra_k@dell.com>
---
drivers/firmware/dmi_scan.c | 26 ++++++++
drivers/pci/Makefile | 3 +
drivers/pci/pci-label.c | 145 +++++++++++++++++++++++++++++++++++++++++++
drivers/pci/pci-sysfs.c | 5 ++
drivers/pci/pci.h | 9 +++
include/linux/dmi.h | 9 +++
6 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 drivers/pci/pci-label.c
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d464672..6894ce4 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -277,6 +277,29 @@ static void __init dmi_save_ipmi_device(const struct dmi_header *dm)
list_add_tail(&dev->list, &dmi_devices);
}
+static void __init dmi_save_dev_onboard(int instance, int segment, int bus,
+ int devfn, const char *name)
+{
+ struct dmi_dev_onboard *onboard_dev;
+
+ onboard_dev = dmi_alloc(sizeof(*onboard_dev) + strlen(name) + 1);
+ if (!onboard_dev) {
+ printk(KERN_ERR "dmi_save_dev_onboard: out of memory.\n");
+ return;
+ }
+ onboard_dev->instance = instance;
+ onboard_dev->segment = segment;
+ onboard_dev->bus = bus;
+ onboard_dev->devfn = devfn;
+
+ strcpy((char *)&onboard_dev[1], name);
+ onboard_dev->dev.type = DMI_DEV_TYPE_DEV_ONBOARD;
+ onboard_dev->dev.name = (char *)&onboard_dev[1];
+ onboard_dev->dev.device_data = onboard_dev;
+
+ list_add(&onboard_dev->dev.list, &dmi_devices);
+}
+
static void __init dmi_save_extended_devices(const struct dmi_header *dm)
{
const u8 *d = (u8*) dm + 5;
@@ -285,6 +308,8 @@ static void __init dmi_save_extended_devices(const struct dmi_header *dm)
if ((*d & 0x80) = 0)
return;
+ dmi_save_dev_onboard(*(d+1), *(u16 *)(d+2), *(d+4), *(d+5),
+ dmi_string_nosave(dm, *(d-1)));
dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
}
@@ -333,6 +358,7 @@ static void __init dmi_decode(const struct dmi_header *dm, void *dummy)
break;
case 41: /* Onboard Devices Extended Information */
dmi_save_extended_devices(dm);
+ break;
}
}
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 0b51857..dc1aa09 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -55,6 +55,9 @@ obj-$(CONFIG_MICROBLAZE) += setup-bus.o
#
obj-$(CONFIG_ACPI) += pci-acpi.o
+# SMBIOS provided firmware instance and labels
+obj-$(CONFIG_DMI) += pci-label.o
+
# Cardbus & CompactPCI use setup-bus
obj-$(CONFIG_HOTPLUG) += setup-bus.o
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
new file mode 100644
index 0000000..170c5bb
--- /dev/null
+++ b/drivers/pci/pci-label.c
@@ -0,0 +1,145 @@
+/*
+ * Purpose: Export the firmware instance/index and label associated with
+ * a pci device to sysfs
+ * Copyright (C) 2010 Dell Inc.
+ * by Narendra K <Narendra_K@dell.com>,
+ * Jordan Hargrave <Jordan_Hargrave@dell.com>
+ *
+ * SMBIOS defines type 41 for onboard pci devices. This code retrieves
+ * the instance number and string from the type 41 record and exports
+ * it to sysfs.
+ *
+ * Please see http://linux.dell.com/wiki/index.php/Oss/libnetdevname for more
+ * information.
+ */
+
+#include <linux/dmi.h>
+#include <linux/sysfs.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include "pci.h"
+
+enum smbios_attr_enum {
+ SMBIOS_ATTR_NONE = 0,
+ SMBIOS_ATTR_LABEL_SHOW,
+ SMBIOS_ATTR_INSTANCE_SHOW,
+};
+
+static mode_t
+find_smbios_instance_string(struct pci_dev *pdev, char *buf, int attribute)
+{
+ const struct dmi_device *dmi;
+ struct dmi_dev_onboard *donboard;
+ int bus;
+ int devfn;
+
+ bus = pdev->bus->number;
+ devfn = pdev->devfn;
+
+ dmi = NULL;
+ while ((dmi = dmi_find_device(DMI_DEV_TYPE_DEV_ONBOARD,
+ NULL, dmi)) != NULL) {
+ donboard = dmi->device_data;
+ if (donboard && donboard->bus = bus &&
+ donboard->devfn = devfn) {
+ if (buf) {
+ if (attribute = SMBIOS_ATTR_INSTANCE_SHOW)
+ return scnprintf(buf, PAGE_SIZE,
+ "%d\n",
+ donboard->instance);
+ else if (attribute = SMBIOS_ATTR_LABEL_SHOW)
+ return scnprintf(buf, PAGE_SIZE,
+ "%s\n",
+ dmi->name);
+ }
+ return strlen(dmi->name);
+ }
+ }
+ return 0;
+}
+
+static mode_t
+smbios_instance_string_exist(struct kobject *kobj, struct attribute *attr,
+ int n)
+{
+ struct device *dev;
+ struct pci_dev *pdev;
+
+ dev = container_of(kobj, struct device, kobj);
+ pdev = to_pci_dev(dev);
+
+ return find_smbios_instance_string(pdev, NULL, SMBIOS_ATTR_NONE);
+}
+
+static ssize_t
+smbioslabel_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct pci_dev *pdev;
+ pdev = to_pci_dev(dev);
+
+ return find_smbios_instance_string(pdev, buf,
+ SMBIOS_ATTR_LABEL_SHOW);
+}
+
+static ssize_t
+smbiosinstance_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct pci_dev *pdev;
+ pdev = to_pci_dev(dev);
+
+ return find_smbios_instance_string(pdev, buf,
+ SMBIOS_ATTR_INSTANCE_SHOW);
+}
+
+static struct device_attribute smbios_attr_label = {
+ .attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbioslabel_show,
+};
+
+static struct device_attribute smbios_attr_instance = {
+ .attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbiosinstance_show,
+};
+
+static struct attribute *smbios_attributes[] = {
+ &smbios_attr_label.attr,
+ &smbios_attr_instance.attr,
+ NULL,
+};
+
+static struct attribute_group smbios_attr_group = {
+ .attrs = smbios_attributes,
+ .is_visible = smbios_instance_string_exist,
+};
+
+static int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ if (!sysfs_create_group(&pdev->dev.kobj, &smbios_attr_group))
+ return 0;
+ return -ENODEV;
+}
+
+static int
+pci_remove_smbiosname_file(struct pci_dev *pdev)
+{
+ sysfs_remove_group(&pdev->dev.kobj, &smbios_attr_group);
+ return 0;
+}
+
+int pci_create_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_create_smbiosname_file(pdev))
+ return 0;
+ return -ENODEV;
+}
+
+int pci_remove_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_remove_smbiosname_file(pdev))
+ return 0;
+ return -ENODEV;
+}
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index afd2fbf..01fd799 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1132,6 +1132,8 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
pci_create_slot_links(pdev);
+ pci_create_firmware_label_files(pdev);
+
return 0;
err_vga_file:
@@ -1201,6 +1203,9 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
sysfs_remove_bin_file(&pdev->dev.kobj, pdev->rom_attr);
kfree(pdev->rom_attr);
}
+
+ pci_remove_firmware_label_files(pdev);
+
}
static int __init pci_sysfs_init(void)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f8077b3..089f402 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -11,6 +11,15 @@
extern int pci_uevent(struct device *dev, struct kobj_uevent_env *env);
extern int pci_create_sysfs_dev_files(struct pci_dev *pdev);
extern void pci_remove_sysfs_dev_files(struct pci_dev *pdev);
+#ifndef CONFIG_DMI
+static inline int pci_create_firmware_label_files(struct pci_dev *pdev)
+{ return 0; }
+static inline int pci_remove_firmware_label_files(struct pci_dev *pdev)
+{ return 0; }
+#else
+extern int pci_create_firmware_label_files(struct pci_dev *pdev);
+extern int pci_remove_firmware_label_files(struct pci_dev *pdev);
+#endif
extern void pci_cleanup_rom(struct pci_dev *dev);
#ifdef HAVE_PCI_MMAP
extern int pci_mmap_fits(struct pci_dev *pdev, int resno,
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index a8a3e1a..90e087f 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -20,6 +20,7 @@ enum dmi_device_type {
DMI_DEV_TYPE_SAS,
DMI_DEV_TYPE_IPMI = -1,
DMI_DEV_TYPE_OEM_STRING = -2,
+ DMI_DEV_TYPE_DEV_ONBOARD = -3,
};
struct dmi_header {
@@ -37,6 +38,14 @@ struct dmi_device {
#ifdef CONFIG_DMI
+struct dmi_dev_onboard {
+ struct dmi_device dev;
+ int instance;
+ int segment;
+ int bus;
+ int devfn;
+};
+
extern int dmi_check_system(const struct dmi_system_id *list);
const struct dmi_system_id *dmi_first_match(const struct dmi_system_id *list);
extern const char * dmi_get_system_info(int field);
--
1.6.5.2
With regards,
Narendra K
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox