* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Greg KH @ 2010-08-20 15:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 04:42:36PM +0200, Wolfgang Wegner wrote:
> Hi list,
>
> I am having a problem with udev on an embedded system and
> am asking for advice on how to track this down. The system is
> an ARM (kirkwood) platform with a busybox-based init. I cross-
> compiled udev-161, made a simple udev start script (basically
> ripped off from debian and stripped from most of the config
> stuff) and a very basic rules file in
> /etc/udev/rules.d/50-udev.rules:
> ACTION="add", KERNEL="sd[a-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk", OPTIONS="last_rule"
> ACTION="remove", KERNEL="sd[a-z][0-9]", RUN+="/bin/umount -l /mnt/usbdisk"
>
> It does not matter if I leave the standard rules in
> /libexec/rules.d/ or if I remove them altogether, in either
> case the USB flash drive is correctly mounted when plugged
> into the running system but not when it is already present when
> the system boots up.
Perhaps because you do not have a 'mount' executable when the device is
found during the boot process?
thanks,
greg k-h
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded system
From: Kay Sievers @ 2010-08-20 15:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 17:00, Wolfgang Wegner <ww-ml@gmx.de> wrote:
> On Fri, Aug 20, 2010 at 04:51:44PM +0200, Kay Sievers wrote:
>> The event for the device happens during early boot where you have no
>> chance to mount. Do you run 'udevadm trigger' at bootup? It will
>> re-generate all events so that they can be handled when userspace is
>> running. It would need --actiond for your current rule to match.
>
> The busybox start script (/etc/init.d/rcS) runs my udev start script
> (/etc/init.d/start_udev.sh) which in turn runs udevadm trigger as
> one of the last steps:
>
> [...]
> udevd --daemon --debug
>
> mkdir -p /dev/.udev/queue/ /dev/.udev/rules.d/
> create_dev_root_rule /dev/.udev/
>
> udevadm trigger
As mentioned, add --actiond. Or make the rule match on 'change' too.
Kay
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-20 16:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 08:29:22AM -0700, Greg KH wrote:
>
> Perhaps because you do not have a 'mount' executable when the device is
> found during the boot process?
/bin/mount is called (successfully) by busybox' init script at the
very beginning, before udev is started.
Thanks for the hint, though.
Regards,
Wolfgang
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-20 16:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 05:31:12PM +0200, Kay Sievers wrote:
> On Fri, Aug 20, 2010 at 17:00, Wolfgang Wegner <ww-ml@gmx.de> wrote:
> > On Fri, Aug 20, 2010 at 04:51:44PM +0200, Kay Sievers wrote:
> >> The event for the device happens during early boot where you have no
> >> chance to mount. Do you run 'udevadm trigger' at bootup? It will
> >> re-generate all events so that they can be handled when userspace is
> >> running. It would need --actiond for your current rule to match.
> >
> > The busybox start script (/etc/init.d/rcS) runs my udev start script
> > (/etc/init.d/start_udev.sh) which in turn runs udevadm trigger as
> > one of the last steps:
> >
> > [...]
> > udevd --daemon --debug
> >
> > mkdir -p /dev/.udev/queue/ /dev/.udev/rules.d/
> > create_dev_root_rule /dev/.udev/
> >
> > udevadm trigger
>
> As mentioned, add --actiond. Or make the rule match on 'change' too.
Thanks, that helped!
I was reading the manpage on my debian box, which is using
udev-125 and thus the documentation is horribly outdated
in some parts, i.e. I was still under the impression --actiond
was the default.
Thanks for the help, now everything works like a charm and I
can think about the proper mount script/command.
Best regards,
Wolfgang
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Karl O. Pinc @ 2010-08-20 16:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On 08/20/2010 11:12:09 AM, Wolfgang Wegner wrote:
> Thanks for the help, now everything works like a charm and I
> can think about the proper mount script/command.
You may wish to look at the latest debian version of
the usbmount package, which uses udev and invokes scripts.
(IIRC)
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded system
From: Bryan Kadzban @ 2010-08-20 16:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 04:42:36PM +0200, Wolfgang Wegner wrote:
> ACTION="remove", KERNEL="sd[a-z][0-9]", RUN+="/bin/umount -l /mnt/usbdisk"
Hmm. You are aware that this won't save you, right? :-)
If someone writes a file into /mnt/usbdisk/... somewhere, and then
unplugs the USB device, this umount call will *not* flush the write out
to disk, and the file will most likely be either lost, or corrupt.
The remove event gets handed to udev *after* the device is already gone.
(And for that matter, the USB hub doesn't provide an event to the host
system until the device is already gone. Once it's gone, you can't
delay its removal, or start any USB transactions, or anything like that:
there's no way to cleanly unmount the FS, or flush out writes, unless
the user tells you beforehand that they're going to be removing the
device.)
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-23 7:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 11:25:07AM -0500, Karl O. Pinc wrote:
> On 08/20/2010 11:12:09 AM, Wolfgang Wegner wrote:
>
> > Thanks for the help, now everything works like a charm and I
> > can think about the proper mount script/command.
>
> You may wish to look at the latest debian version of
> the usbmount package, which uses udev and invokes scripts.
> (IIRC)
Thanks, I will give it a look!
Regards,
Wolfgang
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-23 7:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 09:32:18AM -0700, Bryan Kadzban wrote:
> On Fri, Aug 20, 2010 at 04:42:36PM +0200, Wolfgang Wegner wrote:
> > ACTION="remove", KERNEL="sd[a-z][0-9]", RUN+="/bin/umount -l /mnt/usbdisk"
>
> Hmm. You are aware that this won't save you, right? :-)
Yes, I am - once more you got me for simply copying something
without a deeper look into it. The scripts/commands were simply
copied from either a script formerly used with mdev and from
some udev example I found on the internet. I can only guess that
the intention was to not block udev with the umount in case some
data would have needed to be flushed out. As long as the device
does not work wireless, it is clear there can be no transaction
after the unplug = remove event. :-)
Regards,
Wolfgang
^ permalink raw reply
* [PATCH] Add support for oom_score_adj.
From: Luca Tettamanti @ 2010-08-23 12:35 UTC (permalink / raw)
To: linux-hotplug
/proc/<pid>/oom_adj has been deprecated (kernel v2.6.36) due to the
rework of the badness heuristic; oom_score_adj is the replacement.
Keep a fallback to the old interface for compatibility with older
kernels.
---
udev/udevd.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/udev/udevd.c b/udev/udevd.c
index ad2ca3b..ac2fae0 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -1302,12 +1302,19 @@ int main(int argc, char *argv[])
fclose(f);
}
- /* OOM_DISABLE = -17 */
- fd = open("/proc/self/oom_adj", O_RDWR);
+ fd = open("/proc/self/oom_score_adj", O_RDWR);
if (fd < 0) {
- err(udev, "error disabling OOM: %m\n");
+ /* Fallback to old interface */
+ fd = open("/proc/self/oom_adj", O_RDWR);
+ if (fd < 0) {
+ err(udev, "error disabling OOM: %m\n");
+ } else {
+ /* OOM_DISABLE = -17 */
+ write(fd, "-17", 3);
+ close(fd);
+ }
} else {
- write(fd, "-17", 3);
+ write(fd, "-1000", 5);
close(fd);
}
--
1.7.1
^ permalink raw reply related
* Re[2]: UDEV.
From: Тима @ 2010-08-24 9:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <E1Om6iS-0004CF-00.ge-star-mail-ru@f47.mail.ru>
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>
> On Thu, Aug 19, 2010 at 07:07:40PM +0400, ???? wrote:
> > Thanks.
> > My question (I think) is very easy. But I could not find answer in the Internet, and did not get it on forum.
> > My aim is to make UDEV create device node automatically on loading module.
> > I tied rule:
> > KERNEL="math", NAME="math"
> > meaning my device name (register char dev) is "math" and the node name I want is "math".
> > But nothing happens.
> > Is there any possibility to make such rule?
> > Maybe I do not export some required information to SysFS?
> > If you need module code I can send it to you with Makefile.
>
> Yes, please post your kernel code. You need to hook into the driver
> model to properly be able to have udev pick up your device information.
> Have you done that?
>
> thanks,
>
> greg k-h
Yes, here is my code.
(Sorry for comments in russian. If you need something to understand - ask me and I'll translate it.)
I want kernel to make, for example, /dev/math on loading this module. What should I add to this code or to UDEV rules?
#include <linux/module.h> // Необходим для любого модуля ядра
#include <linux/kernel.h> // Здесь находится определения KERN_*
#include <linux/init.h> // Здесь находятся определения макросов
#include <linux/fs.h> // Фаил для работы с фаиловой системой
#include <asm/uaccess.h> // Определение функции put_user
#include <linux/device.h>
static char *DeviceName = "math";
static char *ParamStr = "NULL";
module_param (ParamStr, charp, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
// Третий аргумент функции - права доступа к соответствующему фаилу в SysFS.
// В нашем случае Read User, Write User, Read Group, Read Others.
MODULE_PARM_DESC (ParamStr, " String Parameter.");
static int DevMajor = -1;
#define STR_LEN 256
static char Expression [STR_LEN];
static char FirstOperand [STR_LEN];
static char SecondOperand [STR_LEN];
static char Answer [STR_LEN];
static int Calculate (void)
{ // Функция выполняющая разбор заданного выражения и вычисление результата.
// Принимает Expression, результат вычислений возвращает в Answer.
int lStr = 0;
int lOperation = -1;
int Operand1, Operand2 = 0;
// lOperation: -1 - "Error"; 0 - "+"; 1 - "-"; 2 - "*"; 3 - "/";
sprintf (Answer, "No Calculated Result.\n");
Answer[strlen ("No Calculated Result.\n")] = 0;
// Ищем знак математической операции:
while (lStr < strlen (Expression))
{
if (Expression[lStr] = '+')
{
lOperation = 0;
break;
} else
if (Expression[lStr] = '-')
{
lOperation = 1;
break;
} else
if (Expression[lStr] = '*')
{
lOperation = 2;
break;
} else
if (Expression[lStr] = '/')
{
lOperation = 3;
break;
};
lStr++;
};
if (lOperation = -1)
{// Если знак операции не найден - выводим подсказку.
sprintf (Answer, "Error in Expression. Please use as \"Operand1 [+, -, *, /] Operand2\".\n");
} else
{
memcpy (FirstOperand, &Expression[0], lStr);
memcpy (SecondOperand, &Expression[lStr + 1], strlen (Expression) - lStr - 1);
Operand1 = simple_strtol (FirstOperand, &FirstOperand, 10);
Operand2 = simple_strtol (SecondOperand, &SecondOperand, 10);
// Сосчитаем что просят:
switch (lOperation)
{
case 0: // +
sprintf (Answer, "%s = %d\n", Expression, Operand1 + Operand2);
break;
case 1: // -
sprintf (Answer, "%s = %d\n", Expression, Operand1 - Operand2);
break;
case 2: // *
sprintf (Answer, "%s = %d\n", Expression, Operand1 * Operand2);
break;
case 3: // /
if (Operand2 = 0)
{
sprintf (Answer, "Sorry, division by Zero is not implemented yet.\n");
} else sprintf (Answer, "%s = %d\n", Expression, Operand1 / Operand2);
break;
default:
sprintf (Answer, "Error in Expression. Please use as \"Operand1 [+, -, *, /] Operand2\".\n");
break;
};
};
return lOperation;
};
static ssize_t DevWrite (struct file * _File, const char __user * _Buffer, size_t _Count, loff_t *_PPos)
{ // Функция отвечает за запись в устройство.
memcpy (&Expression[0], &_Buffer[0], _Count);
Expression[_Count] = 0;
// Вычисляем заданное выражение:
Calculate ();
// Нужно вернуть количество записавшихся (или полученных) байт.
// Иначе будет цикл бесконечной записи в устройство.
// Видимо кернел продолжает попытки записать в устройство если возвращать 0.
// Если устройство вообще не желает принимать данные, нуж но вернуть -EINVAL.
// Но это будет обрабатываться именно как ошибка:
// echo -n "123" > /dev/coffee
// bash: echo: write error: Invalid argument
// Мы выбираем самый приемлемый для нас вариант:
return _Count;
};
static ssize_t DevRead (struct file * _File, char __user * _Buffer, size_t _Count, loff_t *_PPos)
{ // Функция отвечает за чтение из устройства.
size_t BytesWritten = strlen (Answer) - *_PPos;
// Проверяем чтобы запрашиваемая позиция в фаиле не выходила за его размер,
// чтобы предоставляемый буффер был достаточного размера
// и чтобы буффер вообще существовал. Если что-то не так, возвращаем 0
// как признак конца фаила.
if ((*_PPos > strlen (Answer)) || (_Count < strlen (Expression))
|| (!_Buffer)) return 0;
// Т.к. буфер данных находится в пространсвте пользователя,
// а мы находимся в пространстве ядра, то для копирования
// данных в буфер пользователя мы используем функцию copy_to_user:
if (BytesWritten != 0)
{
if (_Count < BytesWritten) BytesWritten = _Count;
copy_to_user (_Buffer, Answer + *_PPos, BytesWritten);
*_PPos += BytesWritten;
}
return BytesWritten;
};
static ssize_t DevRelease (struct inode *_INode, struct file *_File)
{
module_put (THIS_MODULE);
return 0;
};
static ssize_t DevOpen (struct inode *_INode, struct file *_File)
{
try_module_get (THIS_MODULE);
return 0;
};
static const struct file_operations DevOps {
// Здесь мы задаём фнкции, отвечающие за операции с нашим устройством
// и указываем адреса процедур отвечающих за эти операции.
// В нашем случае - чтение из устройства, запись в него и отработка обращений.
.owner = THIS_MODULE,
.read = DevRead,
.write = DevWrite,
.release = DevRelease,
.open = DevOpen
};
int init (void)
{
printk (KERN_INFO "Given Parameter String is \"%s\".\n", ParamStr);
// Запрашиваем динамический старший номер устройства (драйвера - т.е. нас).
// В случае успеха, функция вернет Device Major.
DevMajor = register_chrdev (0, DeviceName, &DevOps);
if ((DevMajor) < 0)
{
printk (KERN_ERR "Error! Char Device Could not be Registerd.\n");
// В любом случае, вернем то что получилось. Пусть лубуются.
return DevMajor;
};
printk ("Use 'mknod /dev/%s c %d 0' to create device file.\n", DeviceName, DevMajor);
// Если вернуть ненулевое значение, то это будет воспринято как ошибка,
// возникшая в процессе работы init_module; и модуль не будет загружен.
sprintf (Expression, "Empty Expression.\n");
sprintf (Answer, "Empty Answer.\n");
return 0;
}
void cleanup (void)
{
// Освобождаем номер, выданный нам ранее.
// С версии 2.6.23 unregister_chrdev возвращает void т.е. ничего.
// Нет возможности проконтролировать работу этой функции.
printk (KERN_INFO "unregister_chrdev ();");
unregister_chrdev (DevMajor, DeviceName);
}
// Начиная с версии 2.3.13, требования к именованию начальной и конечной функций
// модуля были сняты. Достигается это с помощью макроопределений module_init()
// и module_exit(). Воспользуемся этим, т.к. теперь это считается правильно:
module_init (init);
module_exit (cleanup);
// Описание модуля (может быть прочтено программой modinfo):
MODULE_LICENSE("GPL"); // Нужно для функции class_create.
MODULE_AUTHOR("Timofey Chernigovskiy"); // Автор.
MODULE_DESCRIPTION("Math-Device Module"); // Описание.
MODULE_VERSION("0.1"); // Версия.
MODULE_SUPPORTED_DEVICE(DeviceName); // Тип устройств поддерживаемых модулем.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: UDEV.
From: Greg KH @ 2010-08-24 12:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <E1OlfId-0002cX-00.ge-star-mail-ru@f108.mail.ru>
On Tue, Aug 24, 2010 at 01:27:15PM +0400, Тима wrote:
> >
> > A: No.
> > Q: Should I include quotations after my reply?
> >
> > http://daringfireball.net/2007/07/on_top
> >
> > On Thu, Aug 19, 2010 at 07:07:40PM +0400, ???? wrote:
> > > Thanks.
> > > My question (I think) is very easy. But I could not find answer in the Internet, and did not get it on forum.
> > > My aim is to make UDEV create device node automatically on loading module.
> > > I tied rule:
> > > KERNEL="math", NAME="math"
> > > meaning my device name (register char dev) is "math" and the node name I want is "math".
> > > But nothing happens.
> > > Is there any possibility to make such rule?
> > > Maybe I do not export some required information to SysFS?
> > > If you need module code I can send it to you with Makefile.
> >
> > Yes, please post your kernel code. You need to hook into the driver
> > model to properly be able to have udev pick up your device information.
> > Have you done that?
> >
> > thanks,
> >
> > greg k-h
>
> Yes, here is my code.
> (Sorry for comments in russian. If you need something to understand -
> ask me and I'll translate it.) I want kernel to make, for example,
> /dev/math on loading this module. What should I add to this code or to
> UDEV rules?
You need to tie into a class somehow.
The easiest way to do this is to make your driver a 'misc' device and
call misc_register() to get a minor number and register your
file_operations structure. That infrastructure will then set up
everything properly so that udev will automatically create your device
node.
If you don't want to do that, then you need to create your own 'struct
class' and register a device with it after you register your chardev.
See the kernel for lots of examples of how to do this.
Hope this helps,
greg k-h
^ permalink raw reply
* Re: [PATCH] Add support for oom_score_adj.
From: Martin Pitt @ 2010-08-25 14:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1282566937-6604-1-git-send-email-kronos.it@gmail.com>
Hello Luca,
Luca Tettamanti [2010-08-23 14:35 +0200]:
> /proc/<pid>/oom_adj has been deprecated (kernel v2.6.36) due to the
> rework of the badness heuristic; oom_score_adj is the replacement.
> Keep a fallback to the old interface for compatibility with older
> kernels.
This corresponds to
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h¦3d83f427fbce97a6cea0db2e64b0eb8435cd10
I pushed that with that reference, thank you!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* how to force system to mount USB device after it is inserted?
From: hong zhang @ 2010-08-26 0:12 UTC (permalink / raw)
To: linux-hotplug
List,
I want my system to mount a usb device through my own script if my system does not mount it automatically after USB is inserted.
Where should I start to look (that means my script will be called to check if USB is mounted or not when USB device is attached?
Any help will be appreciated!
---henry
^ permalink raw reply
* Re: how to force system to mount USB device after it is inserted?
From: Karl O. Pinc @ 2010-08-26 1:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <657896.51560.qm@web57907.mail.re3.yahoo.com>
On 08/25/2010 07:12:05 PM, hong zhang wrote:
> List,
>
> I want my system to mount a usb device through my own script if my
> system does not mount it automatically after USB is inserted.
>
> Where should I start to look (that means my script will be called to
> check if USB is mounted or not when USB device is attached?
You may find the latest version of the debian usbmount package
helpful.
http://packages.debian.org/sid/usbmount
Note that vfat filesystems will be corrupted unless
they are manually unmounted.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: [PATCH] Add firmware label support to iproute2
From: Matt Domsch @ 2010-08-26 15:01 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Narendra_K, netdev, Charles_Rose, Jordan_Hargrave, linux-pci,
linux-hotplug
In-Reply-To: <20100825171646.3d40b721@nehalam>
On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> On Wed, 25 Aug 2010 17:03:23 -0500
On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> Is it really a good idea to have to change every utility that could
> alter network devices? There is iproute2, iputils, tcpdump, wireshark,
> quagga, snmp, ... Many of the utilities come from a BSD world,
> and will be less likely to accept some Linux specific wart.
I agree, I don't want to have to change all those userspace apps
either. We've started creating patches and are willing to do so if it
will yield the result we want though.
> I have lost faith in this library wrapper support everywhere method.
> Let's just keep the firmware stuff in udev. If the user wants to
> have a policy that renames device from eth0 to "Embedded BIOS LAN1" then
> do it in udev. Or if you want to keep the ethX naming convention
> and stuff the firmware label into ifAlias or other sysfs field
> so it can be displayed that will be not a big issue.
1) we remain constrained to IFNAMSIZ named arguments. There is no
such constraint on BIOS-provided names. Dell BIOS presently uses
'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
awfully close already. I can't dictate to non-Dell BIOS vendors
what to use as their strings, or how long to make them.
digression 1a) udev has a replace-spaces-with-underscores feature I used in
the biosdevname udev rules. That's a reasonable munging of the
provided strings. Much more than that and I'm not sure we could
consistently get it right.
2) there are apps which use a regexp for device names. We'd have to
find and fix those too. Arguably we'd have to do this when we
patch them to use libnetdevname. [1]
3) it continues to force a single naming convention for NICs, where
for other types of devices we can have several independent naming
conventions. I have end users who wish to name their interfaces by
the BIOS label, others by the function (public, dmz,
backup, storage, ...) that the network segment provides. While we
could have different policies, each system can have only one policy
at a time.
David Miller had suggested [2] that we could add a method to get
alternate labels for devices by querying them. We've got something
similar now by exporting the labels for devices in sysfs. Yea -
progress!
But we can't _use_ those labels for more than display
(meaning a human is doing the mapping in their heads), or to rename
devices. We can't use the labels in scripts without doing the label->kernel
name lookups, and then using the kernel name.
I'm open to revisiting the "have udev rename devices", but I tried
that with biosdevname 2 years ago, with little success. Adding in the
hotplug dev team to the thread.
[1] http://marc.info/?l=linux-netdev&m\x125522163322610&w=2 (Marco d'Itri)
[2] http://marc.info/?l=linux-hotplug&m\x123793549323431&w=2
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* RE: [PATCH] Add firmware label support to iproute2
From: Loke, Chetan @ 2010-08-26 15:17 UTC (permalink / raw)
To: Matt Domsch, Stephen Hemminger
Cc: Narendra_K, netdev, Charles_Rose, Jordan_Hargrave, linux-pci,
linux-hotplug
In-Reply-To: <20100826150116.GB21770@auslistsprd01.us.dell.com>
What if we extend 'IFNAMSIZ'(beyond 16 chars. Older apps don't need to
worry because they have been working w/ 16 chars anyways) and also get
ifalias to work in udev(Or is ifalias a bad idea?)?
Chetan
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Matt Domsch
> Sent: August 26, 2010 11:01 AM
> To: Stephen Hemminger
> Cc: Narendra_K@Dell.com; netdev@vger.kernel.org;
Charles_Rose@Dell.com;
> Jordan_Hargrave@Dell.com; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org
> Subject: Re: [PATCH] Add firmware label support to iproute2
>
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > On Wed, 25 Aug 2010 17:03:23 -0500
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > Is it really a good idea to have to change every utility that could
> > alter network devices? There is iproute2, iputils, tcpdump,
> wireshark,
> > quagga, snmp, ... Many of the utilities come from a BSD world,
> > and will be less likely to accept some Linux specific wart.
>
> I agree, I don't want to have to change all those userspace apps
> either. We've started creating patches and are willing to do so if it
> will yield the result we want though.
>
> > I have lost faith in this library wrapper support everywhere method.
> > Let's just keep the firmware stuff in udev. If the user wants to
> > have a policy that renames device from eth0 to "Embedded BIOS LAN1"
> then
> > do it in udev. Or if you want to keep the ethX naming convention
> > and stuff the firmware label into ifAlias or other sysfs field
> > so it can be displayed that will be not a big issue.
>
> 1) we remain constrained to IFNAMSIZ named arguments. There is no
> such constraint on BIOS-provided names. Dell BIOS presently uses
> 'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
> awfully close already. I can't dictate to non-Dell BIOS vendors
> what to use as their strings, or how long to make them.
>
> digression 1a) udev has a replace-spaces-with-underscores feature I
> used in
> the biosdevname udev rules. That's a reasonable munging of the
> provided strings. Much more than that and I'm not sure we could
> consistently get it right.
>
> 2) there are apps which use a regexp for device names. We'd have to
> find and fix those too. Arguably we'd have to do this when we
> patch them to use libnetdevname. [1]
>
> 3) it continues to force a single naming convention for NICs, where
> for other types of devices we can have several independent naming
> conventions. I have end users who wish to name their interfaces by
> the BIOS label, others by the function (public, dmz,
> backup, storage, ...) that the network segment provides. While we
> could have different policies, each system can have only one policy
> at a time.
>
>
> David Miller had suggested [2] that we could add a method to get
> alternate labels for devices by querying them. We've got something
> similar now by exporting the labels for devices in sysfs. Yea -
> progress!
>
> But we can't _use_ those labels for more than display
> (meaning a human is doing the mapping in their heads), or to rename
> devices. We can't use the labels in scripts without doing the label-
> >kernel
> name lookups, and then using the kernel name.
>
> I'm open to revisiting the "have udev rename devices", but I tried
> that with biosdevname 2 years ago, with little success. Adding in the
> hotplug dev team to the thread.
>
>
> [1] http://marc.info/?l=linux-netdev&m\x125522163322610&w=2 (Marco
> d'Itri)
> [2] http://marc.info/?l=linux-hotplug&m\x123793549323431&w=2
>
> --
> Matt Domsch
> Technology Strategist
> Dell | Office of the CTO
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Add firmware label support to iproute2
From: Stephen Hemminger @ 2010-08-26 15:21 UTC (permalink / raw)
To: Loke, Chetan
Cc: Matt Domsch, Narendra_K, netdev, Charles_Rose, Jordan_Hargrave,
linux-pci, linux-hotplug
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B90CEAD321@nsmail.netscout.com>
On Thu, 26 Aug 2010 11:17:51 -0400
"Loke, Chetan" <Chetan.Loke@netscout.com> wrote:
> What if we extend 'IFNAMSIZ'(beyond 16 chars. Older apps don't need to
> worry because they have been working w/ 16 chars anyways) and also get
> ifalias to work in udev(Or is ifalias a bad idea?)?
>
> Chetan
>
That is non-starter for the ioctl() style interface.
struct ifreq {
#define IFHWADDRLEN 6
union
{
char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */
} ifr_ifrn;
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short ifru_flags;
int ifru_ivalue;
int ifru_mtu;
struct ifmap ifru_map;
char ifru_slave[IFNAMSIZ]; /* Just fits the size */
char ifru_newname[IFNAMSIZ];
void __user * ifru_data;
struct if_settings ifru_settings;
} ifr_ifru;
};
Applications do:
strncpy(ifr.ifr_name, "my name", IFNAMSIZ);
ioctl(fd, SIOCGHWADDR, &ifr)
^ permalink raw reply
* RE: [PATCH] Add firmware label support to iproute2
From: Loke, Chetan @ 2010-08-26 15:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matt Domsch, Narendra_K, netdev, Charles_Rose, Jordan_Hargrave,
linux-pci, linux-hotplug
In-Reply-To: <20100826082138.76bcd315@nehalam>
Sorry, my bad.
I agree w/ your recommendation then -
1) stuff it in ifalias(or create a new alias if net_device::ifalias is
used for snmp etc).
But how do we consume it?
1.1) spit it out via sysfs? But Doc/sysfsrules.txt says "Accessing
/sys/class/net/eth0/device is a bug in the application"
Chetan
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: August 26, 2010 11:22 AM
> To: Loke, Chetan
> Cc: Matt Domsch; Narendra_K@Dell.com; netdev@vger.kernel.org;
> Charles_Rose@Dell.com; Jordan_Hargrave@Dell.com; linux-
> pci@vger.kernel.org; linux-hotplug@vger.kernel.org
> Subject: Re: [PATCH] Add firmware label support to iproute2
>
> On Thu, 26 Aug 2010 11:17:51 -0400
> "Loke, Chetan" <Chetan.Loke@netscout.com> wrote:
>
> > What if we extend 'IFNAMSIZ'(beyond 16 chars. Older apps don't need
> to
> > worry because they have been working w/ 16 chars anyways) and also
> get
> > ifalias to work in udev(Or is ifalias a bad idea?)?
> >
> > Chetan
> >
> That is non-starter for the ioctl() style interface.
>
> struct ifreq {
> #define IFHWADDRLEN 6
> union
> {
> char ifrn_name[IFNAMSIZ]; /* if name, e.g.
"en0"
> */
> } ifr_ifrn;
>
> union {
> struct sockaddr ifru_addr;
> struct sockaddr ifru_dstaddr;
> struct sockaddr ifru_broadaddr;
> struct sockaddr ifru_netmask;
> struct sockaddr ifru_hwaddr;
> short ifru_flags;
> int ifru_ivalue;
> int ifru_mtu;
> struct ifmap ifru_map;
> char ifru_slave[IFNAMSIZ]; /* Just fits the size */
> char ifru_newname[IFNAMSIZ];
> void __user * ifru_data;
> struct if_settings ifru_settings;
> } ifr_ifru;
> };
>
> Applications do:
> strncpy(ifr.ifr_name, "my name", IFNAMSIZ);
> ioctl(fd, SIOCGHWADDR, &ifr)
^ permalink raw reply
* Re: [PATCH] Add firmware label support to iproute2
From: Matt Domsch @ 2010-08-26 16:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Narendra_K, netdev, Charles_Rose, Jordan_Hargrave, linux-pci,
linux-hotplug
In-Reply-To: <20100826150116.GB21770@auslistsprd01.us.dell.com>
On Thu, Aug 26, 2010 at 10:01:16AM -0500, Matt Domsch wrote:
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > On Wed, 25 Aug 2010 17:03:23 -0500
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > Is it really a good idea to have to change every utility that could
> > alter network devices? There is iproute2, iputils, tcpdump, wireshark,
> > quagga, snmp, ... Many of the utilities come from a BSD world,
> > and will be less likely to accept some Linux specific wart.
>
> I agree, I don't want to have to change all those userspace apps
> either. We've started creating patches and are willing to do so if it
> will yield the result we want though.
>
> > I have lost faith in this library wrapper support everywhere method.
> > Let's just keep the firmware stuff in udev. If the user wants to
> > have a policy that renames device from eth0 to "Embedded BIOS LAN1" then
> > do it in udev. Or if you want to keep the ethX naming convention
> > and stuff the firmware label into ifAlias or other sysfs field
> > so it can be displayed that will be not a big issue.
>
> 1) we remain constrained to IFNAMSIZ named arguments. There is no
> such constraint on BIOS-provided names. Dell BIOS presently uses
> 'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
> awfully close already. I can't dictate to non-Dell BIOS vendors
> what to use as their strings, or how long to make them.
vlan usage requires 5 characters from IFNAMSIZ (eth0.4095). So my
example with 'Embedded NIC 1' plus a vlan doesn't fit.
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [PATCH] Don't install systemd scripts with --without-systemdsystemunitdir
From: Michael Forney @ 2010-08-27 2:10 UTC (permalink / raw)
To: linux-hotplug
Currently, the scripts get installed to /no/ if that option is
specified.
---
configure.ac | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0a18bb6..31c5b18 100644
--- a/configure.ac
+++ b/configure.ac
@@ -66,8 +66,10 @@ AC_SUBST([FIRMWARE_PATH], [$FIRMWARE_PATH])
AC_ARG_WITH([systemdsystemunitdir],
AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files]),
[], [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)])
-AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])
-AM_CONDITIONAL(WITH_SYSTEMD, [test -n "$with_systemdsystemunitdir"])
+if test "x$with_systemdsystemunitdir" != xno; then
+ AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])
+fi
+AM_CONDITIONAL(WITH_SYSTEMD, [test -n "$with_systemdsystemunitdir" -a "x$with_systemdsystemunitdir" != xno ])
AC_ARG_ENABLE([extras],
AS_HELP_STRING([--disable-extras], [disable extras with external dependencies]),
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH] Add firmware label support to iproute2
From: Kay Sievers @ 2010-08-27 7:54 UTC (permalink / raw)
To: Loke, Chetan
Cc: Stephen Hemminger, Matt Domsch, Narendra_K, netdev, Charles_Rose,
Jordan_Hargrave, linux-pci, linux-hotplug
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B90CEAD362@nsmail.netscout.com>
On Thu, Aug 26, 2010 at 17:38, Loke, Chetan <Chetan.Loke@netscout.com> wrote:
> Sorry, my bad.
> I agree w/ your recommendation then -
> 1) stuff it in ifalias(or create a new alias if net_device::ifalias is
> used for snmp etc).
>
> But how do we consume it?
> Â 1.1) spit it out via sysfs? But Doc/sysfsrules.txt says "Accessing
> /sys/class/net/eth0/device is a bug in the application"
You walk up the parent devices of the netdev until you find the one
you are looking for. The "device" link is broken by design and might
just point to the first parent device. The kernel is free to insert
devices into the device tree if needed, and then the device link
target may change.
/sys/class/net/eth0 is a symlink pointing to a location the
/sys/devices tree, like:
../../devices/pci0000:00/0000:00:19.0/net/eth0
One of the parent devices of the eth0 device has this attribute., but
you can never be sure that it's just the next parent (broken concept
of the device link), you have to walk up the chain of parents.
You can just use udev to that automatically and extract the value, and
pass it with the event for the eth0 device.
Kay
^ permalink raw reply
* Do not create persistent name rules for KVM network interfaces
From: Marco d'Itri @ 2010-08-27 16:35 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 17 bytes --]
--
ciao,
Marco
[-- Attachment #2: blacklist_kvm_macs --]
[-- Type: text/plain, Size: 747 bytes --]
Do not create persistent name rules for KVM network interfaces.
The virtual interfaces created by KVM are stable, 54:52:00 is the MAC-48
range of KVM: http://www.coffer.com/mac_find/?string=545200 .
--- a/extras/rule_generator/75-persistent-net-generator.rules
+++ b/extras/rule_generator/75-persistent-net-generator.rules
@@ -29,6 +29,9 @@ ENV{MATCHADDR}="$attr{address}"
# match interface type
ENV{MATCHIFTYPE}="$attr{type}"
+# ignore KVM virtual interfaces
+ENV{MATCHADDR}=="54:52:00:*", GOTO="persistent_net_generator_end"
+
# These vendors are known to violate the local MAC address assignment scheme
# Interlan, DEC (UNIBUS or QBUS), Apollo, Cisco, Racal-Datacom
ENV{MATCHADDR}=="02:07:01:*", GOTO="globally_administered_whitelist"
^ permalink raw reply
* udev-161-1 breaks DVD-ROM
From: Борис Васильев @ 2010-08-28 10:23 UTC (permalink / raw)
To: linux-hotplug
Hi, sorry for the bad English. I confirm the bug described in:
http://bugs.archlinux.org/task/20550?string=udev&project=1&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto
"Details
Description:
udev version udev-161-1 breaks DVD-ROM functionality on my computer.
After upgrade, putting in a DVD with data shows up as a blank DVD in GNOME.
reinstalling Udev 1.6.0-1 fixes everything
Additional info:
udev-161-1
Steps to reproduce:
put in a DVD with videos, pictures etc.. and it will show up as a blank
cd/DVD"
My system:
Linux arch 2.6.35-ARCH #1 SMP PREEMPT Sat Aug 21 07:23:08 UTC 2010 i686
Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz GenuineIntel GNU/Linux, GNOME
2.30, CD-ROM: PIONEER DVD-RW DVR-212 1.24 PQ
Yours respectfully, Boris Vasilev/bobart@mail.ru
^ permalink raw reply
* Re: udev-161-1 breaks DVD-ROM
From: Martin Pitt @ 2010-08-30 8:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.vh48hu1jee43hi@localhost.localdomain>
Hello Борис,
Борис Васильев [2010-08-28 14:23 +0400]:
> udev version udev-161-1 breaks DVD-ROM functionality on my computer.
> After upgrade, putting in a DVD with data shows up as a blank DVD in GNOME.
I can't reproduce that here, so I need further debugging info. Can you
please give me the output of
/lib/udev/cdrom_id --debug /dev/sr0
with the DVD-ROM in the drive for both version 160 and version 161?
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: udev-161-1 breaks DVD-ROM
From: Martin Pitt @ 2010-08-30 8:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.vh48hu1jee43hi@localhost.localdomain>
Martin Pitt [2010-08-30 10:14 +0200]:
> I can't reproduce that here, so I need further debugging info. Can you
> please give me the output of
>
> /lib/udev/cdrom_id --debug /dev/sr0
>
> with the DVD-ROM in the drive for both version 160 and version 161?
Nevermind, those are already on the downstream bug. Will look there.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ 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