| Age | Commit message (Collapse) | Author |
|---|
|
On Tue, Sep 07, 2004 at 12:46:43PM +0200, Kay Sievers wrote:
> On Mon, 2004-09-06 at 20:18 -0700, Tom Rini wrote:
> > I noticed somewhat recently that my enet devices weren't being renamed
> > on boot anymore. I don't quite know when this got broken (or rather, if
> > it was supposed to be working. I swear it worked for me once..), but
> > the following seems to do it.
>
> I think it never worked in the udevstart case. It worked only with the
> hotplug-event-udev, I expect.
>
> > In udev_scan_class(), look for not just
> > %s/%s/dev (which everything with a dev node has), but %s/%s/dev* (both
> > of my enet devices, sis900 & 3c59x only have device) and if that
> > exists, pass this along to udev.
>
> Yeah, network devices don't have a devnode and therefore no "dev", but
> they are all in /sys/class/net/. We may just test if we are there
> instead of the "device" match.
How about something like this. It adds all the net devices without
looking at the attributes and keeps the remaining logic like it is.
It also removes certain levels of indirection and much simplifies the
udevstart process. We surely don't need to open and close the udevdb
for every node while iterating over the list. (We are about 5% faster on
my box)
It's not well tested, so it would be nice if someone can have a look
at it, before a broken udevstart renders any system unbootable.
|
|
On Mon, 2004-09-06 at 17:45 +0200, Kay Sievers wrote:
> On Mon, 2004-09-06 at 16:46 +0200, David Zeuthen wrote:
>
> Nice, I like it. It's a easy way to group device nodes of the same type,
> but coming from different kernel subsystems.
>
That's a good way of putting it, yeah.
> > Here's a patch against udev-030 that can help create compatibility
> > symlinks like /dev/cdrom, /dev/cdrom1 etc. The patch introduces a new
> > substitution type %C (for Compatibility) that can be used as follows
>
> I suggest using %e for enumeration here, cause "compatibility" can
> easily be misunderstood.
>
Good point, I've changed that.
> And we need a few lines added to the man page at udev.8.in :)
>
Done. I've also added an example.
Also, Kay pointed out offlist that the rules can be written to not
require a shell script; this actually works
KERNEL="sr*", NAME="%k", SYMLINK="cdrom%e"
KERNEL="scd*", NAME="%k", SYMLINK="cdrom%e"
KERNEL="pcd*", NAME="%k", SYMLINK="cdrom%e"
KERNEL="hd[a-z]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom", NAME="\%k", SYMLINK="cdrom%e"
KERNEL="fd[0-9]", NAME="%k", SYMLINK="floppy%e"
KERNEL="hd[a-z]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="floppy", NAME=\"%k", SYMLINK="floppy%e"
New patch is attached.
David
|
|
Hi Kay,
On 23:12 Sat 04 Sep , Kay Sievers wrote:
> Cool, a real bug :)
> Thanks, for the patch. I think it would be better to skip lenghth exceeding
> lines instead of cutting it and continue. While looking at it I restructured
> the buffer reading logic a bit and fixed another stupid bug.
Thanks for the cleanup.
You may have overlooked the fix for udev_config.c(parsing udev.conf) in
your patch. So, I've adapted the fixes you applied to namedev_parse.c
to this file also.
Also, while 'eating' the whitespace the 'count' doesn't get decremented.
This leads strncpy to copy the number of whitespace minus 1 characters
from the next line. Minus 1 because it copies '\n' from the current
line.
while (isspace(bufline[0])) {
bufline++;
+ count--;
}
.
.
.
strncpy(line, bufline, count);
Included patch(against udev-030) contains the above fixes as well as
your fixes.
Signed-off-by: Arun Bhanu <arun@codemovers.org>
|
|
make -j doesnt work with current udev.
|
|
Here is an update for the volume_id callout to catch up to the latest
and greatest:
o It is able to skip the label reading of linux raid members, which are
otherwise recognized as a normal filesystem.
o It reads FAT labels stored in the directory instead of the
superblock (Windows only writes in the directory).
o The NTFS uuid is the right one now.
o It reads all the Apple HFS(+) formats with the labels.
o UFS volumes are recognized but no labels are extracted.
o We use CFLAGS+=-D_FILE_OFFSET_BITS=64 instead of lsee64() which may fix
a bug mentioned on the klibc mailing list.
A lot of other new features are only used in HAL and not needed in this
simple callout. But if someone stumbles over it and want's to send a patch
for some exotic formats, we better keep it up to date :)
|
|
We ran into problems with all the /etc/hotplug.d/ scripts that sleep for
the sysfs files or for other reasons. Anyway, it takes much too much time
before udev is executed.
HAL has its own notifier in /etc/hotplug.d/ and also waits for the
dev.d/events with the same SEQNUM. Sometimes it take 25 seconds between
these two events, cause the other scripts are sleeping too much :)
Attached is a patch that installs the udevsend symlink as
10-udev.hotplug instead of udev.hotplug, to be executed earlier.
[kay@pim udev.kay]$ tree /etc/hotplug.d/
/etc/hotplug.d/
`-- default
|-- 10-udev.hotplug -> /sbin/udevsend
|-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
`-- default.hotplug
|
|
here we change udevd to pass the SEQNUM from the hotplug environment
to udev and the dev.d/ scripts. We need this for HAL to match the
hotplug event with the dev.d/ events.
It also changes the type from int to long to match the kernel.
|
|
Thanks to Martin Schlemmer <azarah@nosferatu.za.org> for the fix.
|
|
|
|
|
|
On Mon, Jul 12, 2004 at 11:14:28AM -0400, esr@thyrsus.com wrote:
> This is automatically generated email about problems in a man page for which
> you appear to be responsible. If you are not the right person or list, tell
> me and I will attempt to correct my database.
>
> See http://catb.org/~esr/doclifter/problems.html for details on how and
> why these patches were generated. Feel free to email me with any questions.
>
> Note: This patch does not change the mod date of the manual page. You
> may wish to do that by hand.
>
> Problems with udevd.8:
>
> 1. There are multiple name lines. This makes it impossible to translate
> the page to DocBook. It may also confuse some implementations
> of man -k.
>
> --- udevd.8-orig 2004-07-10 06:35:12.032545856 -0400
> +++ udevd.8 2004-07-10 06:36:19.301319448 -0400
> @@ -1,8 +1,6 @@
> .TH UDEVD 8 "February 2004" "" "Linux Administrator's Manual"
> .SH NAME
> -udevd \- udev event serializer daemon
> -.br
> -udevsend \- sends the event to udevd
> +udevd, udevdsend \- udev event serializer daemon and udev event sender
> .SH SYNOPSIS
> --
> Eric S. Raymond
>
Thanks Eric, udevsend.8 is only a symlink to udevd.8, so I attached a
stripped down patch to this mail.
|
|
The attached patch contains a few patches against udev, to remove
use of various XSI:isms and bash:isms, and to change two scripts form
/bin/bash to /bin/sh. None of the bash-scripts in test/ uses any
bash-specific functions as far as I know, but I didn't touch them since
they aren't used runtime.
Rationale:
* Both of the /bin/bash-scripts are totally free from bashisms, hence they
don't need to be /bin/bash; using /bin/sh instead helps (mainly)
embedded-people
* local and source are bash:isms (well, they exist in several other
shells as well, but they aren't part of POSIX or any of its extensions)
* -a in tests is an XSI-extension, not part of strict POSIX, and is
easily replaced by &&
| http://www.opengroup.org/onlinepubs/009695399/utilities/test.html
* Use of fgrep is deprecated in POSIX in favour of grep -F (though fgrep
will remain in use for a long time...)
| http://www.opengroup.org/onlinepubs/009695399/utilities/grep.html
The fgrep-change isn't really necessary, since fgrep can always be
implemented as a shell-script, but the rest of the changes would really
be appreciated.
|
|
Move setting UDEV_NO_SLEEP into main(). I thought about moving
udev_init_config() around, but it still must be invoked in both udev and
udevstart cases, and before udev_hotplug() is called. An alternative
would be to have main() do:
if (is_udevstart) {
... current ...
} else {
udev_init_config();
return udev_hotplug();
}
And move setting UDEV_NO_SLEEP into udev_start(). I can redo it that
way, if you prefer.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
First, update extras/start_udev. udevstart always internally set
UDEV_NO_SLEEP as well as setting the ACTION variable, so that only needs
to be done in the run_udev script case.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
Add microcode rule, remove duplicate rtc and psaux rules,
and order alphabetically.
|
|
Hi,
The following patch makes udev/udevstart be a common binary. First,
doing this grows udev by a total of 1.8kB (ppc32, stripped) whereas
udevstart by itself is 6.4kB. I know you mentioned being able to
replace udevstart with a script, but at 1.8kB I don't think it'll be
easy to beat this with size there. Next, the following are by-eye
timings of before, after, and with devfs on a slow, but still usable
embedded platform (config stripped down to more-or-less bare for
ramdisk):
-- Embedded Planet RPX LITE, 64Mhz MPC 823e --
devfs : 15.333s, 15.253s, 14.988s (15.191s avg)
udev-pristine : 18.675s, 18.079s, 18.418s (18.390s avg)
udev-multi : 14.587s, 14.747s, 14.868s (14.734s avg)
The patch ends up being rather large to add this, as in doing so I ended
up making all refs (that I hit..) to devpath/subsystem be marked as
'const'.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
The following patch adds 'asmlinkage' defines to udev, to kill off 2
warnings on !i386.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
|
|
|
|
|
|
|
|
|
|
NAME_SIZE is too small for some configurations. This patch allows more
or longer names, it just keeps the stack in a sane state.
|
|
|
|
|
|
Should fix the dm startup issues, hopefully...
|
|
|
|
|
|
|
|
I noticed a comment in namedev.c which stated
"Figure out where the device symlink is at. For char devices this will
always be in the class_dev->path. But for block devices, it's
different. The main block device will have the device symlink in it's
path, but all partitions have the symlink in its parent directory. But
we need to watch out for block devices that do not have parents, yet
look like a partition (fd0, loop0, etc.). They all do not have a device
symlink yet. We do a sit and spin on waiting for them right now, we
should possibly have a whitelist for these devices here..."
I went ahead and created a whitelist for the block devices that look
like partitions (mainly by using devices.txt) and tested for any
performance increase that we would see. The whitelist only impacts
udevstart time depending on the state of UDEV_NO_SLEEP. Since the list
was short, I just did a sequential search and ordered the list in such a
way that those block devices which have more /dev entires (ex. loop0,
loop1, loop2, etc) appear sooner in the list and will thus be found
quicker. I've enclosed the patch and some of the performance results I
saw below. Basically, as the number of block devices without device
symlinks increased, the use of the whitelist improved udevstart
performance compared to just sitting and spinning. I just thought it
was interesting and thought I'd share. If you feel the patch is
beneficial please consider for merging. Also, if you'd be interested in
expanding the whitelist for other devices which are missing device
symlinks and seeing if there are added performance increases let me know
and I'll do what I can. Thanks,
Leann
Note: ex. loop represents all the loop devices (i.e. loop0, loop1,
loop2, etc)
block devices present with whitelist time
|
|
volume_id is now able to read NTFS labels. Not very exciting, but we
keep up to date with the version in HAL. Also __packed__ was needed for
the structs, cause the gcc 3.4 compiled version was no longer working
properly.
|
|
This patch syncs the scsi_id in the udev tree to version 0.5.
|
|
Here's an update to the documentation. It makes a few minor corrections and
adds info about multiple-symlinks.
It also seems that the patch I sent on April 27th (patching v0.53 to 0.54) was
not applied, so this patch includes that update too, which was also just some
small corrections plus added info on renaming network devices.
|
|
|
|
this should fix the startup issue for lvm, hopefully...
|
|
|
|
|
|
and misc devices.
|
|
There is a handle leak in failure path in file_map, and the result of
file_map (or the result of the caller of the file_map) is not always
checked.
|
|
|
|
The recent version of klibc switched to -mregparm=3. This broke the
signal handlers parameter, cause it is called directly from the kernel
with the parameter on the stack not in a register.
|
|
|
|
Our own implementation of the sysinfo system call is no longer
needed, cause it's merged it into klibc now.
|
|
because kernel.org is down, no release just yet...
|
|
|
|
Some file locations have changed since the spec file was last updated.
Also a failed build might leave behind a stale buildroot directory.
This patch should fix both problems.
|
|
Small patch to fix the evaluation logic for the return value of getenv()
in udev_config.c file. Basically, the actual values for the environment
variables "UDEV_NO_SLEEP" and "UDEV_NO_DEVD" were not being checked.
For example UDEV_NO_SLEEP could have been set to false but the line:
if (getenv("UDEV_NO_SLEEP") != NULL)
in this case would always evaluate to true, since getenv() returns
char*, thus the "udev_sleep" variable would be set incorrectly. The
patch makes sure to check the value returned by getenv() not just if
getenv() returned a value. Hope this made sense. Thanks,
|
|
On Tue, May 11, 2004 at 04:54:44PM -0700, Greg KH wrote:
> On Tue, May 11, 2004 at 01:16:41PM +0200, Kay Sievers wrote:
> > Hi,
> > the execution of udev depends on the proper fuction of udevd, the
> > serializing daemon. If we can't connect to udevd within a 20 second we
> > give up and the request to create a node is lost. Hope this never happens,
> > but a broken udevd may prevent udev from working.
> >
> > What do you think? Should we call the udev binary directly from udevsend
> > instead of discarding the event? This way we would create the node, regardless
> > of the state of udevd. It would be 20 seconds later and maybe not in the right
> > sequence order - but the node will propably be there.
> >
> > Does it sound sane? What do you think?
>
> That sounds like a good "failsafe" thing to do.
Here we go:
Add a fallback udev call to udevsend. If udevsend is unable to send the
event to udevd, we call the udev binary instead of doing nothing and exiting.
|
|
|
|
|
