* udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-15 17:25 UTC (permalink / raw)
To: linux-hotplug
Just a heads-up, because some tools like to "look into" /dev/.udev/.
With udev 167 there will be no /dev/.udev/ directory anymore.
The maintainers of the commonly used early-boot tools agreed to use a
/dev/.run/<package>/ dir instead, which will be provided by initramfs
and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
will be available at /var/run/. The /dev/.run/ directory is at that
point just an "early-boot alias" for /var/run/, and all early-boot
tools will have their data in /var/run/, just like any other service.
In the end, there should be no custom .-dirs left in /dev, besides
this "alias".
The command 'udevadm info --convert-db' is also gone. The udev daemon
converts any old database if needed on startup:
[ 3.708616] systemd-fsck[344]: Root directory is writable, skipping check.
[ 3.796452] udev[359]: converting old udev database
[ 3.856218] udev[359]: starting version 167
The udev source change is here:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h_59fa0900a5c127ce1a25d8ba3176f166662f96
If you support LVM, please make sure to conflict udev if neccessary
with older initramfs implementations, so that no new udev gets into an
old initramfs image, udev puts the data in /dev/.run/ which isn't its
own mountpoint, and the real root would overmount the udev directory.
Thanks,
Kay
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Marco d'Itri @ 2011-03-15 17:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Mar 15, Kay Sievers <kay.sievers@vrfy.org> wrote:
> The maintainers of the commonly used early-boot tools agreed to use a
> /dev/.run/<package>/ dir instead, which will be provided by initramfs
> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
> will be available at /var/run/. The /dev/.run/ directory is at that
> point just an "early-boot alias" for /var/run/, and all early-boot
> tools will have their data in /var/run/, just like any other service.
This looks complex and requiring coordination among multiple packages.
Where is the documentation of everything which needs to be done by the
surrounding boot scripts?
Will anything break if I still create an empty /dev/.udev/ for the
benefit of everything which checks for it to know if udev is running?
> If you support LVM, please make sure to conflict udev if neccessary
> with older initramfs implementations, so that no new udev gets into an
> old initramfs image, udev puts the data in /dev/.run/ which isn't its
> own mountpoint, and the real root would overmount the udev directory.
I am not sure that I understand this sentence.
--
ciao,
Marco
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-15 23:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Tue, Mar 15, 2011 at 18:38, Marco d'Itri <md@linux.it> wrote:
> On Mar 15, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> The maintainers of the commonly used early-boot tools agreed to use a
>> /dev/.run/<package>/ dir instead, which will be provided by initramfs
>> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
>> will be available at /var/run/. The /dev/.run/ directory is at that
>> point just an "early-boot alias" for /var/run/, and all early-boot
>> tools will have their data in /var/run/, just like any other service.
> This looks complex and requiring coordination among multiple packages.
> Where is the documentation of everything which needs to be done by the
> surrounding boot scripts?
I can't know, or document anything. The init scripts I maintain do not
know anything about /dev/.udev/.
> Will anything break if I still create an empty /dev/.udev/ for the
> benefit of everything which checks for it to know if udev is running?
I wouldn't do that. But it should work, if you don't create the db/
dir there, that would trigger the built-in converter. And please don't
make it a symlink to /dev/.run/, I don't know how that behaves.
Anyway, if you really still need that check, you should probably add a
command to 'udevadm info ...' using the libudev check, instead of
poking directories.
>> If you support LVM, please make sure to conflict udev if neccessary
>> with older initramfs implementations, so that no new udev gets into an
>> old initramfs image, udev puts the data in /dev/.run/ which isn't its
>> own mountpoint, and the real root would overmount the udev directory.
> I am not sure that I understand this sentence.
LVM needs the udev database from initramfs to be preserved.
Non-adapted initramfs images with the new udev might not create the
/dev/.run/ mountpoint, and any new init system will just overmount the
entire /dev/.run/ from initramfs, and the udev database is gone and
LVM will not find the udev database ....
Kay
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Marco d'Itri @ 2011-03-15 23:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Mar 16, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >> The maintainers of the commonly used early-boot tools agreed to use a
> >> /dev/.run/<package>/ dir instead, which will be provided by initramfs
> >> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
> >> will be available at /var/run/. The /dev/.run/ directory is at that
> >> point just an "early-boot alias" for /var/run/, and all early-boot
> >> tools will have their data in /var/run/, just like any other service.
> > This looks complex and requiring coordination among multiple packages.
> > Where is the documentation of everything which needs to be done by the
> > surrounding boot scripts?
> I can't know, or document anything. The init scripts I maintain do not
> know anything about /dev/.udev/.
I am talking about this new /dev/.run/ thing. Where is it documented?
--
ciao,
Marco
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-15 23:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Wed, Mar 16, 2011 at 00:09, Marco d'Itri <md@linux.it> wrote:
> On Mar 16, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> >> The maintainers of the commonly used early-boot tools agreed to use a
>> >> /dev/.run/<package>/ dir instead, which will be provided by initramfs
>> >> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
>> >> will be available at /var/run/. The /dev/.run/ directory is at that
>> >> point just an "early-boot alias" for /var/run/, and all early-boot
>> >> tools will have their data in /var/run/, just like any other service.
>> > This looks complex and requiring coordination among multiple packages.
>> > Where is the documentation of everything which needs to be done by the
>> > surrounding boot scripts?
>> I can't know, or document anything. The init scripts I maintain do not
>> know anything about /dev/.udev/.
> I am talking about this new /dev/.run/ thing. Where is it documented?
So far only in code in systemd and dracut and the SUSE mkinitrd. It's
just a plain directory udev uses like /dev/.udev/ was. Udev itself
does not know anything about it. Old initramfs and init will just not
care, and udev just has a new directory with that name to put its
stuff into.
If modern initramfs and init are used, it is a tmpfs mountpoint that
will be the same as /var/run/.
Kay
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Scott James Remnant @ 2011-03-16 0:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> If modern initramfs and init are used, it is a tmpfs mountpoint that
> will be the same as /var/run/.
>
I'm sick of this definition of "modern" to mean whatever you want ...
has this been even discussed with the authors or maintainers of any
other initramfs implementation than dracut?
Scott
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-16 0:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> If modern initramfs and init are used, it is a tmpfs mountpoint that
>> will be the same as /var/run/.
>>
> I'm sick of this definition of "modern" to mean whatever you want ...
> has this been even discussed with the authors or maintainers of any
> other initramfs implementation than dracut?
You will recover from that sickness, I hope. :)
Kay
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Scott James Remnant @ 2011-03-16 0:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Tue, Mar 15, 2011 at 5:20 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
>> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>
>>> If modern initramfs and init are used, it is a tmpfs mountpoint that
>>> will be the same as /var/run/.
>>>
>> I'm sick of this definition of "modern" to mean whatever you want ...
>> has this been even discussed with the authors or maintainers of any
>> other initramfs implementation than dracut?
>
> You will recover from that sickness, I hope. :)
>
That wasn't answering the question.
Have you discussed this with the authors or maintainers of any other
initramfs implementation then dracut?
Also:
Has a kernel patch been proposed for the vast majority of Linux
installations that aren't using either an initramfs or systemd?
Scott
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Scott James Remnant @ 2011-03-16 0:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Tue, Mar 15, 2011 at 10:25 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> The maintainers of the commonly used early-boot tools agreed to use a
> /dev/.run/<package>/ dir instead, which will be provided by initramfs
> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
> will be available at /var/run/. The /dev/.run/ directory is at that
> point just an "early-boot alias" for /var/run/, and all early-boot
> tools will have their data in /var/run/, just like any other service.
> In the end, there should be no custom .-dirs left in /dev, besides
> this "alias".
>
Kay has clarified in IM that the /dev/.run directory is bind-mounted
to /var/run later in the boot, so it's available at both paths always.
If other distros ignore that, then it's just a change of path for
udev.
Which makes me wonder why this is necessary at all. Modern distros
have a tmpfs mounted on /var/run at all phases of the boot, mounting
it in the initramfs, binding it to the target filesystem, and ensuring
that it remains mounted even if an intermediate /var is placed in the
way.
So udev could simply use /var/run/udev all the time anyway
Scott
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-16 0:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Wed, Mar 16, 2011 at 01:34, Scott James Remnant <scott@netsplit.com> wrote:
> On Tue, Mar 15, 2011 at 10:25 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Which makes me wonder why this is necessary at all. Â Modern distros
> have a tmpfs mounted on /var/run at all phases of the boot, mounting
> it in the initramfs, binding it to the target filesystem, and ensuring
> that it remains mounted even if an intermediate /var is placed in the
> way.
>
> So udev could simply use /var/run/udev all the time anyway
Not really, it wouldn't work well on older systems without /var/run on
tmpfs, or separate /var.
The only sane alternative anyway is to introduce /run, not to fiddle
around an make assumptions what we have around on on-disk filesystems
on bootup.
Kay
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Greg KH @ 2011-03-16 1:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Tue, Mar 15, 2011 at 05:23:27PM -0700, Scott James Remnant wrote:
> On Tue, Mar 15, 2011 at 5:20 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
> >> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >>
> >>> If modern initramfs and init are used, it is a tmpfs mountpoint that
> >>> will be the same as /var/run/.
> >>>
> >> I'm sick of this definition of "modern" to mean whatever you want ...
> >> has this been even discussed with the authors or maintainers of any
> >> other initramfs implementation than dracut?
> >
> > You will recover from that sickness, I hope. :)
> >
> That wasn't answering the question.
>
> Have you discussed this with the authors or maintainers of any other
> initramfs implementation then dracut?
What other ones are actively developed these days?
> Has a kernel patch been proposed for the vast majority of Linux
> installations that aren't using either an initramfs or systemd?
Why would the kernel care about this?
confused,
greg k-h
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Scott James Remnant @ 2011-03-16 1:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Tue, Mar 15, 2011 at 6:11 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Mar 15, 2011 at 05:23:27PM -0700, Scott James Remnant wrote:
>> On Tue, Mar 15, 2011 at 5:20 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> > On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
>> >> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> >>
>> >>> If modern initramfs and init are used, it is a tmpfs mountpoint that
>> >>> will be the same as /var/run/.
>> >>>
>> >> I'm sick of this definition of "modern" to mean whatever you want ...
>> >> has this been even discussed with the authors or maintainers of any
>> >> other initramfs implementation than dracut?
>> >
>> > You will recover from that sickness, I hope. :)
>> >
>> That wasn't answering the question.
>>
>> Have you discussed this with the authors or maintainers of any other
>> initramfs implementation then dracut?
>
> What other ones are actively developed these days?
>
initramfs-tools is very actively developed
Scott
^ permalink raw reply
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number
From: Jesse Barnes @ 2011-03-16 17:41 UTC (permalink / raw)
To: Shyam_Iyer
Cc: Narendra_K, greg, a.beregalov, linux-next, linux-pci,
linux-hotplug, netdev, mjg, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, sfr
In-Reply-To: <DBFB1B45AF80394ABD1C807E9F28D157026585D732@BLRX7MCDC203.AMER.DELL.COM>
On Fri, 11 Mar 2011 03:35:56 +0530
<Shyam_Iyer@Dell.com> wrote:
>
> > -----Original Message-----
> > From: K, Narendra
> > Sent: Monday, March 07, 2011 3:56 PM
> > To: Greg KH
> > Cc: a.beregalov@gmail.com; linux-next@vger.kernel.org;
> > jbarnes@virtuousgeek.org; linux-pci@vger.kernel.org; linux-
> > hotplug@vger.kernel.org; netdev@vger.kernel.org; mjg@redhat.com;
> > Domsch, Matt; Rose, Charles; Hargrave, Jordan; Iyer, Shyam;
> > sfr@canb.auug.org.au
> > Subject: Re: [PATCH V4] Export ACPI _DSM provided firmware instance
> > number and string name to sysfs
> >
> > On Tue, Mar 08, 2011 at 01:26:16AM +0530, Greg KH wrote:
> > > On Mon, Mar 07, 2011 at 11:44:52AM -0800, Narendra_K@Dell.com wrote:
> > > > --- a/drivers/pci/pci-label.c
> > > > +++ b/drivers/pci/pci-label.c
> > > > @@ -29,7 +29,9 @@
> > > > #include <linux/nls.h>
> > > > #include <linux/acpi.h>
> > > > #include <linux/pci-acpi.h>
> > > > +#ifdef CONFIG_ACPI
> > > > #include <acpi/acpi_drivers.h>
> > > > +#endif
> > >
> > > You should never need a #ifdef in a .c file for an include file. If
> > so,
> > > something is really wrong.
> >
> > I agree. Also, i realized that the include was not required to address
> > the
> > reported error. Please find the revised patch here.
> >
> > From: Narendra K <narendra_k@dell.com>
> > Subject: [PATCH] Fix compilation error when CONFIG_ACPI is unset
> >
> > This patch fixes compilation error descibed below introduced by
> > the commit 6058989bad05b82e78baacce69ec14f27a11b5fd
> >
> > drivers/pci/pci-label.c: In function ‘pci_create_firmware_label_files’:
> > drivers/pci/pci-label.c:366:2: error: implicit declaration of function
> > ‘device_has_dsm’
> >
> > Signed-off-by: Narendra K <narendra_k@dell.com>
> > ---
> > drivers/pci/pci-label.c | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> > index 824e247..8c80138 100644
> > --- a/drivers/pci/pci-label.c
> > +++ b/drivers/pci/pci-label.c
> > @@ -174,6 +174,12 @@ pci_remove_acpi_index_label_files(struct pci_dev
> > *pdev)
> > return -1;
> > }
> >
> > +static inline bool
> > +device_has_dsm(struct device *dev)
> > +{
> > + return false;
> > +}
> > +
> > #else
> >
> > static const char device_label_dsm_uuid[] = {
> > --
> > 1.7.3.1
> >
> > With regards,
> > Narendra K
>
> So this works and fixes the additional build failure.
>
> I tested with CONFIG_ACPI set/unset and with "make allmodconfig"
>
> Additionally I found that including acpi/apci_drivers.h is not necessary and introduces these warnings..
>
> The below patch fixes the additional warnigs..
>
> In file included from drivers/pci/pci-label.c:32:
> include/acpi/acpi_drivers.h:103: warning: ‘struct acpi_device’ declared inside parameter list
> include/acpi/acpi_drivers.h:103: warning: its scope is only this definition or declaration, which is probably not what you want
> include/acpi/acpi_drivers.h:107: warning: ‘struct acpi_pci_root’ declared inside parameter list
>
> Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
Ok, I've applied these two fixes, thanks guys. I hope that's the last
of the issues we'll see with this patch!
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Andrey Borzenkov @ 2011-03-17 10:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Wed, Mar 16, 2011 at 3:34 AM, Scott James Remnant <scott@netsplit.com> wrote:
> On Tue, Mar 15, 2011 at 10:25 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> The maintainers of the commonly used early-boot tools agreed to use a
>> /dev/.run/<package>/ dir instead, which will be provided by initramfs
>> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
>> will be available at /var/run/. The /dev/.run/ directory is at that
>> point just an "early-boot alias" for /var/run/, and all early-boot
>> tools will have their data in /var/run/, just like any other service.
>> In the end, there should be no custom .-dirs left in /dev, besides
>> this "alias".
>>
> Kay has clarified in IM that the /dev/.run directory is bind-mounted
> to /var/run later in the boot, so it's available at both paths always.
> If other distros ignore that, then it's just a change of path for
> udev.
>
> Which makes me wonder why this is necessary at all. Modern distros
> have a tmpfs mounted on /var/run at all phases of the boot,
there are several packages in Mandriva that install subdirectories in
/var/run and simply expect them to be present at any time. My first
try at tmpfs-mount /var/run under systemd was disaster. While I can
fix all those packages to install tmpfiles.d under systemd, I do not
see what can be sensibly done without (except extracting tmpfiles.d
from systemd into separate package).
So the question is - is all of this still going to work without this bind mount?
> mounting
> it in the initramfs, binding it to the target filesystem, and ensuring
> that it remains mounted even if an intermediate /var is placed in the
> way.
>
> So udev could simply use /var/run/udev all the time anyway
>
please, do not! For the reasons above ...
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Lennart Poettering @ 2011-03-17 14:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Thu, 17.03.11 13:24, Andrey Borzenkov (arvidjaar@gmail.com) wrote:
> > Kay has clarified in IM that the /dev/.run directory is bind-mounted
> > to /var/run later in the boot, so it's available at both paths always.
> > If other distros ignore that, then it's just a change of path for
> > udev.
> >
> > Which makes me wonder why this is necessary at all. Modern distros
> > have a tmpfs mounted on /var/run at all phases of the boot,
>
> there are several packages in Mandriva that install subdirectories in
> /var/run and simply expect them to be present at any time. My first
> try at tmpfs-mount /var/run under systemd was disaster. While I can
> fix all those packages to install tmpfiles.d under systemd, I do not
> see what can be sensibly done without (except extracting tmpfiles.d
> from systemd into separate package).
>
> So the question is - is all of this still going to work without this
> bind mount?
For now I don't think too many things will break if /var/run is not a
tmpfs, and if /var/run is not bind mounted to /dev/.run. But sooner or
later this will probably break...
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* Re: Fwd: [PATCH] Remap MSI Laptop touchpad on/off key to F22 and F23
From: Martin Pitt @ 2011-03-18 13:55 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
Hello Joey,
Joey Lee [2011-03-16 1:06 -0600]:
> P: /devices/virtual/input/input7
> E: UDEV_LOG=3
> E: DEVPATH=/devices/virtual/input/input7
> E: PRODUCT=19/0/0/0
> E: NAME="MSI Laptop hotkeys"
> E: PHYS="msi-laptop/input0"
> E: EV==3
> E: KEY==180000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> E: MODALIAS=input:b0019v0000p0000e0000-e0,1,k213,214,ramlsfw
> E: SUBSYSTEM=input
Ah, thanks for this data. This indeed helped to demonstrate the
problem. First I added some debugging output to input_id [1].
While debugging I got an overflow, because your data is apparently
from a 32 bit machine/kernel, while I'm running 64 bit. I fixed that
as well while I was at it [2]. After fudging the data to be in the
proper 64 bit format, I was able to see what the KEY_MAX problem was.
Unfortunately the KEY_* and BTN_* blocks are alternating in
linux/input.h, so the fix looks a bit unelegant, but it works now [3].
Thanks!
Martin
[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=941c40bdc47d1fdee651558dd0e162cd8d674fab
[2] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=88149f668ea7ac23c61f6d1982db4f4517da763c
[3] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=792479aca54d266430c900f90557ea8d0da2c125
--
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: 836 bytes --]
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Scott James Remnant @ 2011-03-18 22:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Thu, Mar 17, 2011 at 7:39 AM, Lennart Poettering
<lennart@poettering.net> wrote:
> For now I don't think too many things will break if /var/run is not a
> tmpfs, and if /var/run is not bind mounted to /dev/.run. But sooner or
> later this will probably break...
>
For non-distribution Linux installs, having that extra mount is an
extra syscall on boot that could be done without.
Do you think it'd be a problem if software could have the option to
use /var/run directly without going through the /dev/.run alias?
(I guess this would be as simple as a configure option for thems that wants it)
Scott
^ permalink raw reply
* Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-19 5:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=P5wbg5nO7ufsM-7ZntxunX4+HX18wpGnyjSkh@mail.gmail.com>
On Fri, Mar 18, 2011 at 23:12, Scott James Remnant <scott@netsplit.com> wrote:
> On Thu, Mar 17, 2011 at 7:39 AM, Lennart Poettering
> <lennart@poettering.net> wrote:
>
>> For now I don't think too many things will break if /var/run is not a
>> tmpfs, and if /var/run is not bind mounted to /dev/.run. But sooner or
>> later this will probably break...
>>
> For non-distribution Linux installs, having that extra mount is an
> extra syscall on boot that could be done without.
>
> Do you think it'd be a problem if software could have the option to
> use /var/run directly without going through the /dev/.run alias?
>
> (I guess this would be as simple as a configure option for thems that wants it)
Seems, after the last round of discussion we got for a simple /run
tmpfs now, and all these issues and fiddling with directories on an
on-disk /var will go away.
Kay
^ permalink raw reply
* Re: [PATCH V3] Export ACPI _DSM provided firmware instance number and
From: Alexander Beregalov @ 2011-03-20 10:15 UTC (permalink / raw)
To: Narendra_K
Cc: mjg59, linux-pci, linux-hotplug, netdev, Matt_Domsch,
Charles_Rose, Jordan_Hargrave, Shyam_Iyer
In-Reply-To: <20110223132147.GB16707@fedora14-r610.blr.amer.dell.com>
On 23 February 2011 16:00, <Narendra_K@dell.com> wrote:
> On Wed, Feb 23, 2011 at 06:14:19PM +0530, Matthew Garrett wrote:
>> I think this version will still break the build. You need to depend on
>> CONFIG_NLS.
>
> Matthew,
>
> Thanks. I posted a patch to linux-next to fix the build failure.
Hi,
it still does not work
drivers/pci/Kconfig:
select NLS if (DMI || ACPI)
$ egrep "G_ACPI=|_DMI=|G_NLS=" .config
CONFIG_DMI=y
CONFIG_ACPI=y
CONFIG_NLS=m
pci-label.c:(.text+0xb80a): undefined reference to `utf16s_to_utf8s'
^ permalink raw reply
* Re: [PATCH V3] Export ACPI _DSM provided firmware instance number
From: Narendra_K @ 2011-03-21 15:30 UTC (permalink / raw)
To: a.beregalov
Cc: mjg59, linux-pci, linux-hotplug, netdev, Matt_Domsch,
Charles_Rose, Jordan_Hargrave, Shyam_Iyer
In-Reply-To: <AANLkTiki5XdEe1QjP6_GfkFGD39odyVES_yC4QcQc33z@mail.gmail.com>
On Sun, Mar 20, 2011 at 03:45:33PM +0530, Alexander Beregalov wrote:
> On 23 February 2011 16:00, <Narendra_K@dell.com> wrote:
> > On Wed, Feb 23, 2011 at 06:14:19PM +0530, Matthew Garrett wrote:
> >> I think this version will still break the build. You need to depend on
> >> CONFIG_NLS.
> >
> > Matthew,
> >
> > Thanks. I posted a patch to linux-next to fix the build failure.
>
> Hi,
> it still does not work
>
> drivers/pci/Kconfig:
> select NLS if (DMI || ACPI)
>
> $ egrep "G_ACPI=|_DMI=|G_NLS=" .config
> CONFIG_DMI=y
> CONFIG_ACPI=y
> CONFIG_NLS=m
>
> pci-label.c:(.text+0xb80a): undefined reference to `utf16s_to_utf8s'
Hi,
With '2.6.38' mainline kernel + 'patch-v2.6.38-next-20110321', i could
not see this issue. With CONFIG_DMI=y and CONFIG_ACPI=y, CONFIG_NLS is
set to 'y' even when doing an 'allmodconfig' because of the
'select NLS if (DMI || ACPI)' in drivers/pci/Kconfig.
Please let me know if i am missing something so that i can
replicate this failure.
With regards,
Narendra K
^ permalink raw reply
* Re: Fwd: [PATCH] Remap MSI Laptop touchpad on/off key to F22
From: Joey Lee @ 2011-03-22 4:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110318135541.GB4231@piware.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 1544 bytes --]
Hi Martin,
æ–¼ 五，2011-03-18 æ–¼ 14:55 +0100，Martin Pitt æ到：
> Hello Joey,
>
> Joey Lee [2011-03-16 1:06 -0600]:
> > P: /devices/virtual/input/input7
> > E: UDEV_LOG=3
> > E: DEVPATH=/devices/virtual/input/input7
> > E: PRODUCT\x19/0/0/0
> > E: NAME="MSI Laptop hotkeys"
> > E: PHYS="msi-laptop/input0"
> > E: EV=3
> > E: KEY=180000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > E: MODALIAS=input:b0019v0000p0000e0000-e0,1,k213,214,ramlsfw
> > E: SUBSYSTEM=input
>
> Ah, thanks for this data. This indeed helped to demonstrate the
> problem. First I added some debugging output to input_id [1].
>
> While debugging I got an overflow, because your data is apparently
> from a 32 bit machine/kernel, while I'm running 64 bit. I fixed that
> as well while I was at it [2]. After fudging the data to be in the
> proper 64 bit format, I was able to see what the KEY_MAX problem was.
> Unfortunately the KEY_* and BTN_* blocks are alternating in
> linux/input.h, so the fix looks a bit unelegant, but it works now [3].
>
> Thanks!
>
> Martin
>
> [1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h”1c40bdc47d1fdee651558dd0e162cd8d674fab
> [2] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hˆ149f668ea7ac23c61f6d1982db4f4517da763c
> [3] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hy2479aca54d266430c900f90557ea8d0da2c125
I applied the above patches to udev 166 and it works fine with my
msi-laptop driver's input device. :-)
Thank's a lot!
Joey Lee
^ permalink raw reply
* Udev
From: Paulo Eliseu Weber @ 2011-03-22 19:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20050811182850.GD15803@kroah.com>
Hello,
I wonder which version of Udev is compatible with kernel 2.6.16 (Debian).
Thanks.
^ permalink raw reply
* Re: Udev
From: Kay Sievers @ 2011-03-22 19:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20050811182850.GD15803@kroah.com>
On Tue, Mar 22, 2011 at 20:48, Paulo Eliseu Weber
<pauloe.weber@yahoo.com.br> wrote:
> I wonder which version of Udev is compatible with kernel 2.6.16 (Debian).
This is the upstream development list, where almost nobody runs such
old stuff anymore. Please try if the Debian guys know anything about
it, there are much more distro specific dependencies than kernel ones.
Kay
^ permalink raw reply
* Udev remove --type failed logic
From: Seblu @ 2011-03-24 2:05 UTC (permalink / raw)
To: linux-hotplug
Hello,
I see in TODO from last git commit, that --type failed logic will be
removed from udev.
I trying to patch an issue in my archlinux with bluetoothd and udev
rules wich start it.
One idea was to extend add RUN{fail_event_on_error} in place of RUN,
to recall it after dbus was started.
But it's seems you will remove this feature from udev.
Why remove it?
What is your recommendation about those cases?
Regards,
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: Udev remove --type failed logic
From: Andrey Borzenkov @ 2011-03-24 3:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTin+2CTXo=Vw9K=FUWei7Wa-nKbamu-ExbWG-OdR@mail.gmail.com>
On Thu, Mar 24, 2011 at 5:05 AM, Seblu <seblu@seblu.net> wrote:
> Hello,
>
> I see in TODO from last git commit, that --type failed logic will be
> removed from udev.
>
> I trying to patch an issue in my archlinux with bluetoothd and udev
> rules wich start it.
> One idea was to extend add RUN{fail_event_on_error} in place of RUN,
> to recall it after dbus was started.
>
That is exactly what I have done to fix missing BT after standard
services were removed and replaced by udev activation.
> But it's seems you will remove this feature from udev.
>
> Why remove it?
Hmm ... I presume it is removal of systemd unit, hopefully not removal
of support of option from udevadm. Under systemd this should not be
required indeed under most conditions. And udev never shipped
initscripts, this was always distribution responsibility - here
nothing changes.
> What is your recommendation about those cases?
>
^ permalink raw reply
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