Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-05 Thread David Matthews 
Oliver Endriss wrote:
 Janne Grunau wrote:
 Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
 result in deterministic dvb adapter numbers.

 Besides following changes in dvb-core and dvb-usb core the patch adds to
 all drivers 
 ...
 
 While I don't care much whether there is an option for this in the
 driver, I'd like to point out that this is the wrong approach (imho).
 
 Citing Greg Kroah-Hartman (udev-113/docs/udev_vs_devfs):
 |...
 |2) udev does not care about the major/minor number schemes.  If the
 |   kernel tomorrow switches to randomly assign major and minor numbers
 |   to different devices, it would work just fine (this is exactly
 |   what I am proposing to do in 2.7...)
 |3) This is the main reason udev is around.  It provides the ability
 |   to name devices in a persistent manner.  More on that below.
 |...
 
 According to this, adding such an option is a step into the wrong
 direction. The right way is to fix the udev scripts...

I've just written udev rules for my set-up.  udev may be the correct way 
to do this but it is far from easy.  Having the adapter number specified 
as a driver option would be much simpler.

I have an Opera DVB-S USB device and a Nova T-500 containing two DVB-T 
devices.  Depending on whether the Opera is in warm or cold state the 
kernel may number the Opera as 0 and the two Nova devices as 1 and 2 or 
the Nova as 0 and 1 with the Opera as 2. For Myth, though, I want to be 
sure that the Opera has a specific device (e.g. /dev/dvb/adapter7/*) 
while the Nova devices have two other specific devices (e.g. 
/dev/dvb/adapter0/* and /dev/dvb/adapter1/*).

Writing a udev rule to pin the Opera to a specific adapter number was 
fairly easy.  Since there is only a single device I could match on the 
USB identifiers.  The Nova, though, has two devices and these are 
indistinguishable, at least from what udevinfo provides.  That means 
that it isn't possible to write a udev rule that would match one device 
and make it /dev/dvb/adapter0 and a different rule to make the other 
/dev/dvb/adapter1.  I was reduced to writing a script that would detect 
whether /dev/dvb/adapter{0,1} existed and if it did whether the entries 
that were already in that directory had the same minor device number 
divided by 64 as the minor device number of new device, divided by 64. 
This was the only way to make sure that /dev/dvb/adapter0 and 
/dev/dvb/adapter1 contained the correct devices and entries weren't 
mixed up.

There may be another way to do this but I couldn't think of one.  Maybe 
the Nova device driver should be changed to ensure the two devices are 
distinguishable in some way.  If udev is being relied upon as the only 
way to pin device entries there needs to be a library of udev rules for 
each device that people can copy.  Otherwise I think Janne's patch is a 
sensible way to go.

David.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-05 Thread Janne Grunau 
On Sunday 05 August 2007 06:01:46 Oliver Endriss wrote:
 Janne Grunau wrote:
  Hi,
 
  Dynamic loading of modules by udev on startup (aka coldplugging)
  doesn't result in deterministic dvb adapter numbers.
 
  Besides following changes in dvb-core and dvb-usb core the patch
  adds to all drivers
  ...

 While I don't care much whether there is an option for this in the
 driver, I'd like to point out that this is the wrong approach (imho).

 Citing Greg Kroah-Hartman (udev-113/docs/udev_vs_devfs):
 |...
 |2) udev does not care about the major/minor number schemes.  If
 | the kernel tomorrow switches to randomly assign major and minor
 | numbers to different devices, it would work just fine (this is
 | exactly what I am proposing to do in 2.7...)
 |3) This is the main reason udev is around.  It provides the
 | ability to name devices in a persistent manner.  More on that
 | below. ...

 According to this, adding such an option is a step into the wrong
 direction. The right way is to fix the udev scripts...

I'm not sure that this is actually consent on lkml and not just Greg 
Kroah-Hartman's opinion.
I find the module options much more conveniant than writing udev rules 
myself. The automatic persistent network interface generator as used by 
Gentoo atm has issues (it's not possible to just change a broken nic 
without changing udev rules).

Janne

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-04 Thread Janne Grunau 
On Saturday 04 August 2007 07:00:42 you wrote:
 On 8/4/07, Manu Abraham [EMAIL PROTECTED] wrote:
  On 8/4/07, Michael Krufky [EMAIL PROTECTED] wrote:
   Manu Abraham wrote:
On 8/4/07, Janne Grunau [EMAIL PROTECTED] wrote:
On Saturday 04 August 2007 00:02:29 Manu Abraham wrote:
Do we really want to have adapter numbers in DVB bridge
drivers ? IMHO, it doesn't look pleasing to have that.
   
I think it's worthwhile to have it.
   
Is there any other possible better alternatives ?
   
Something similiar is possible with udev rules but I wouldn't
say that it is a better alternative.
   
Why ? If you can achieve the same without any code change,
doesn't that look better ?
  
   using a module option to specify adapter number is a _much_ more
   user friendly solution, as opposed to udev rules.
 
  Yuck. I just wonder why other char drivers in the Linux kernel do
  not have such a necessity, you have the same problem there as well.

The video4linux driver have this.

 btw, though not directly related this thread on LK deals with the
 same root cause
 http://lkml.org/lkml/2007/8/2/82

The thread shows why I prefer my patch over a udev solution.

1. The numbers in the kernel log will match the contents of /dev/dvb

2. The patch will handle the replacement of one card with the same type 
and shuffling of cards in your PCI slots while udev will break one of 
them. Udev can either identify the cards by path (this will break 
shuffling of cards) or by ids (mac, usb serial no) (this will break 
replacement).

So I think the patch has its merits.

Janne


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Michael Krufky 
Janne Grunau wrote:
 Hi,
 
 Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
 result in deterministic dvb adapter numbers.
 
 V4L drivers have the {radio|vbi|video}_nr module options to allocate
 static minor numbers per driver.
 Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
 problems with device unplugging and repluging each driver holds
 a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
 options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
 reversed allocation of adapter numbers.
 With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
 are already in use it will allocate the lowest free adapter number.
 
 Besides following changes in dvb-core and dvb-usb core the patch adds to
 all drivers 
 
 +static int adapter_nr[] = {[0 ... (DVB_MAX_ADAPTERS - 1)] = DVB_UNSET };
 +module_param_array(adapter_nr, int, NULL, 0444);
 +MODULE_PARM_DESC(adapter_nr,DVB adapter numbers);
 
 and modifies the dvb_register_adapter call. Full patch is attached as
 compressed file.
 
 With the exception of dvb-usb I have just added the paramter to the module
 with the dvb_register_adapter() call. budget-core and videobuf-dvb are
 affected for example. I'll push the option to the driver which uses these
 modules after we reached consent on the approach.
 
 Janne 

I like this a lot -- In fact, I think I love it.  I don't have anything negative
to say about this at all.  I've always wanted a module option for this.  True,
it can be done with udev, but that's no reason not to move forward.

I say Janne should continue on and convert the rest of the drivers... Is anybody
opposed?

Cheers,

Mike

-- 
Michael Krufky


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Manu Abraham 
On 8/2/07, Janne Grunau [EMAIL PROTECTED] wrote:
 Hi,

 Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
 result in deterministic dvb adapter numbers.

 V4L drivers have the {radio|vbi|video}_nr module options to allocate
 static minor numbers per driver.
 Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
 problems with device unplugging and repluging each driver holds
 a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
 options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
 reversed allocation of adapter numbers.
 With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
 are already in use it will allocate the lowest free adapter number.

 Besides following changes in dvb-core and dvb-usb core the patch adds to
 all drivers

 +static int adapter_nr[] = {[0 ... (DVB_MAX_ADAPTERS - 1)] = DVB_UNSET };
 +module_param_array(adapter_nr, int, NULL, 0444);
 +MODULE_PARM_DESC(adapter_nr,DVB adapter numbers);

 and modifies the dvb_register_adapter call. Full patch is attached as
 compressed file.

Do we really want to have adapter numbers in DVB bridge drivers ?
IMHO, it doesn't look pleasing to have that.

Is there any other possible better alternatives ? If it is that
absolute a necessity, can we hide the ugliness in dvb-core at least ?

(Although dvb-core is becoming a nightmare, with lot of cruft, i don't
see anything that's going to clear up any time soon, but rather
increase over time, with backward compatibility and things like that)

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Janne Grunau 
On Friday 03 August 2007 21:28:01 Michael Krufky wrote:
 I say Janne should continue on and convert the rest of the drivers...
 Is anybody opposed?

done

Janne
Adds adapter_nr module parameter to all dvb drivers to specify the
preferred allocation of device minor numbers per driver.

Signed-off-by: Janne Grunau [EMAIL PROTECTED]
Index: v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/b2c2/flexcop.c
+++ v4l-dvb/linux/drivers/media/dvb/b2c2/flexcop.c
@@ -64,10 +64,10 @@ static int flexcop_dvb_stop_feed(struct 
 	return flexcop_pid_feed_control(fc,dvbdmxfeed,0);
 }
 
-static int flexcop_dvb_init(struct flexcop_device *fc)
+static int flexcop_dvb_init(struct flexcop_device *fc, int *adapter_nums)
 {
 	int ret;
-	if ((ret = dvb_register_adapter(fc-dvb_adapter,FlexCop Digital TV device,fc-owner,fc-dev))  0) {
+	if ((ret = dvb_register_adapter(fc-dvb_adapter,FlexCop Digital TV device,fc-owner,fc-dev,adapter_nums))  0) {
 		err(error registering DVB adapter);
 		return ret;
 	}
@@ -243,7 +243,7 @@ void flexcop_device_kfree(struct flexcop
 }
 EXPORT_SYMBOL(flexcop_device_kfree);
 
-int flexcop_device_initialize(struct flexcop_device *fc)
+int flexcop_device_initialize(struct flexcop_device *fc, int *adapter_nums)
 {
 	int ret;
 	ibi_zero.raw = 0;
@@ -255,7 +255,7 @@ int flexcop_device_initialize(struct fle
 
 	flexcop_smc_ctrl(fc, 0);
 
-	if ((ret = flexcop_dvb_init(fc)))
+	if ((ret = flexcop_dvb_init(fc, adapter_nums)))
 		goto error;
 
 	/* do the MAC address reading after initializing the dvb_adapter */
Index: v4l-dvb/linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ v4l-dvb/linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -42,6 +42,8 @@ static int debug;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, Turn on/off debugging (default:off).);
 
+DVB_ADAPTER_NR_MODULE_PARAM
+
 #define dprintk( args... ) \
 	do \
 		if (debug) printk(KERN_DEBUG args); \
@@ -717,7 +719,7 @@ static int __devinit dvb_bt8xx_load_card
 {
 	int result;
 
-	if ((result = dvb_register_adapter(card-dvb_adapter, card-card_name, THIS_MODULE, card-bt-dev-dev))  0) {
+	if ((result = dvb_register_adapter(card-dvb_adapter, card-card_name, THIS_MODULE, card-bt-dev-dev, adapter_nr))  0) {
 		printk(dvb_bt8xx: dvb_register_adapter failed (errno = %d)\n, result);
 		return result;
 	}
Index: v4l-dvb/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
+++ v4l-dvb/linux/drivers/media/dvb/cinergyT2/cinergyT2.c
@@ -61,6 +61,8 @@ static int debug;
 module_param_named(debug, debug, int, 0644);
 MODULE_PARM_DESC(debug, Turn on/off debugging (default:off).);
 
+DVB_ADAPTER_NR_MODULE_PARAM
+
 #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,15)
 #define dprintk(level, args...)		\
 do {	\
@@ -992,7 +994,7 @@ static int cinergyt2_probe (struct usb_i
 		return -ENOMEM;
 	}
 
-	if ((err = dvb_register_adapter(cinergyt2-adapter, DRIVER_NAME, THIS_MODULE, cinergyt2-udev-dev))  0) {
+	if ((err = dvb_register_adapter(cinergyt2-adapter, DRIVER_NAME, THIS_MODULE, cinergyt2-udev-dev, adapter_nr))  0) {
 		kfree(cinergyt2);
 		return err;
 	}
Index: v4l-dvb/linux/drivers/media/dvb/dvb-core/dvbdev.c
===
--- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvbdev.c
+++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvbdev.c
@@ -53,7 +53,6 @@ static const char * const dnames[] = {
 	net, osd
 };
 
-#define DVB_MAX_ADAPTERS	8
 #define DVB_MAX_IDS		4
 #define nums2minor(num,type,id)	((num  6) | (id  4) | type)
 #define MAX_DVB_MINORS		(DVB_MAX_ADAPTERS*64)
@@ -286,21 +285,25 @@ void dvb_unregister_device(struct dvb_de
 }
 EXPORT_SYMBOL(dvb_unregister_device);
 
+static int dvbdev_check_free_adapter_num(int num)
+{
+	struct list_head *entry;
+	list_for_each (entry, dvb_adapter_list) {
+		struct dvb_adapter *adap;
+		adap = list_entry (entry, struct dvb_adapter, list_head);
+if (adap-num == num)
+			return 0;
+	}
+return 1;
+}
 
 static int dvbdev_get_free_adapter_num (void)
 {
 	int num = 0;
 
 	while (num  DVB_MAX_ADAPTERS) {
-		struct list_head *entry;
-		list_for_each (entry, dvb_adapter_list) {
-			struct dvb_adapter *adap;
-			adap = list_entry (entry, struct dvb_adapter, list_head);
-			if (adap-num == num)
-goto skip;
-		}
-		return num;
-skip:
+		if (dvbdev_check_free_adapter_num(num))
+			return num;
 		num++;
 	}
 
@@ -308,13 +311,27 @@ skip:
 }
 
 
-int dvb_register_adapter(struct dvb_adapter *adap, const char *name, struct module *module, struct device *device)
+int dvb_register_adapter(struct dvb_adapter *adap, const char *name, struct module *module, struct device *device, int *adapter_nums)
 {
-	int num;
+	int i, num;

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Michael Krufky 
Manu Abraham wrote:
 On 8/2/07, Janne Grunau [EMAIL PROTECTED] wrote:
 Hi,

 Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
 result in deterministic dvb adapter numbers.

 V4L drivers have the {radio|vbi|video}_nr module options to allocate
 static minor numbers per driver.
 Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
 problems with device unplugging and repluging each driver holds
 a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
 options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
 reversed allocation of adapter numbers.
 With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
 are already in use it will allocate the lowest free adapter number.

 Besides following changes in dvb-core and dvb-usb core the patch adds to
 all drivers

 +static int adapter_nr[] = {[0 ... (DVB_MAX_ADAPTERS - 1)] = DVB_UNSET };
 +module_param_array(adapter_nr, int, NULL, 0444);
 +MODULE_PARM_DESC(adapter_nr,DVB adapter numbers);

 and modifies the dvb_register_adapter call. Full patch is attached as
 compressed file.
 
 Do we really want to have adapter numbers in DVB bridge drivers ?
 IMHO, it doesn't look pleasing to have that.
 
 Is there any other possible better alternatives ? If it is that
 absolute a necessity, can we hide the ugliness in dvb-core at least ?
 
 (Although dvb-core is becoming a nightmare, with lot of cruft, i don't
 see anything that's going to clear up any time soon, but rather
 increase over time, with backward compatibility and things like that)

Manu,

Please see Janne's latest patch.  Does that satisfy your concern?  Rather than
adding the repeated code in every driver, he used a macro, and things look quite
clean.

I like this a lot, and I'd like to commit it, if nobody speaks against it.
Would you say it's fair if I wait until Sunday before doing so?

Regards,

Michael Krufky


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Janne Grunau 
On Saturday 04 August 2007 00:02:29 Manu Abraham wrote:

 Do we really want to have adapter numbers in DVB bridge drivers ?
 IMHO, it doesn't look pleasing to have that.

I think it's worthwhile to have it.

 Is there any other possible better alternatives ?

Something similiar is possible with udev rules but I wouldn't say that 
it is a better alternative.

 If it is that 
 absolute a necessity, can we hide the ugliness in dvb-core at least ?

I'm not really sure what you mean exactly. If you want to avoid changes 
in the bridge drivers I don't see a way to archieve that. If you want 
the changes as small as possible look at the final patch. One line for 
the module parameter and the added parameter for the register function. 
I don't think it can be done with less changes.

Janne

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Manu Abraham 
On 8/4/07, Janne Grunau [EMAIL PROTECTED] wrote:
 On Saturday 04 August 2007 00:02:29 Manu Abraham wrote:
 
  Do we really want to have adapter numbers in DVB bridge drivers ?
  IMHO, it doesn't look pleasing to have that.

 I think it's worthwhile to have it.
 
  Is there any other possible better alternatives ?

 Something similiar is possible with udev rules but I wouldn't say that
 it is a better alternative.


Why ? If you can achieve the same without any code change, doesn't
that look better ?


  If it is that
  absolute a necessity, can we hide the ugliness in dvb-core at least ?

 I'm not really sure what you mean exactly. If you want to avoid changes
 in the bridge drivers I don't see a way to archieve that. If you want
 the changes as small as possible look at the final patch.


That one looks better than your first patch. (Although i hate having a
MAX limit defined)

I meant adding a module parameter to each module, which was a bit, ..
I don't know how come others said that they liked the first one very
much.


 One line for
 the module parameter and the added parameter for the register function.
 I don't think it can be done with less changes.


True.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Michael Krufky 
Manu Abraham wrote:
 On 8/4/07, Janne Grunau [EMAIL PROTECTED] wrote:
 On Saturday 04 August 2007 00:02:29 Manu Abraham wrote:
 Do we really want to have adapter numbers in DVB bridge drivers ?
 IMHO, it doesn't look pleasing to have that.
 I think it's worthwhile to have it.
 Is there any other possible better alternatives ?
 Something similiar is possible with udev rules but I wouldn't say that
 it is a better alternative.
 
 Why ? If you can achieve the same without any code change, doesn't
 that look better ?

using a module option to specify adapter number is a _much_ more user friendly 
solution, as opposed to udev rules.


 If it is that
 absolute a necessity, can we hide the ugliness in dvb-core at least ?
 I'm not really sure what you mean exactly. If you want to avoid changes
 in the bridge drivers I don't see a way to archieve that. If you want
 the changes as small as possible look at the final patch.
 
 That one looks better than your first patch. (Although i hate having a
 MAX limit defined)

The MAX limit was already there beforehand -- Janne only moved the setting of 
it from dvbdev.c to dvbdev.h.

 I meant adding a module parameter to each module, which was a bit, ..
 I don't know how come others said that they liked the first one very
 much.

I liked the concept... of course the macro is much cleaner looking.

 One line for
 the module parameter and the added parameter for the register function.
 I don't think it can be done with less changes.
 
 
 True.

-MiKE

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-03 Thread Manu Abraham 
On 8/4/07, Michael Krufky [EMAIL PROTECTED] wrote:
 Manu Abraham wrote:
  On 8/4/07, Janne Grunau [EMAIL PROTECTED] wrote:
  On Saturday 04 August 2007 00:02:29 Manu Abraham wrote:
  Do we really want to have adapter numbers in DVB bridge drivers ?
  IMHO, it doesn't look pleasing to have that.
  I think it's worthwhile to have it.
  Is there any other possible better alternatives ?
  Something similiar is possible with udev rules but I wouldn't say that
  it is a better alternative.
 
  Why ? If you can achieve the same without any code change, doesn't
  that look better ?

 using a module option to specify adapter number is a _much_ more user 
 friendly solution, as opposed to udev rules.



Yuck. I just wonder why other char drivers in the Linux kernel do not
have such a necessity, you have the same problem there as well.


  If it is that
  absolute a necessity, can we hide the ugliness in dvb-core at least ?
  I'm not really sure what you mean exactly. If you want to avoid changes
  in the bridge drivers I don't see a way to archieve that. If you want
  the changes as small as possible look at the final patch.
 
  That one looks better than your first patch. (Although i hate having a
  MAX limit defined)

 The MAX limit was already there beforehand -- Janne only moved the setting of 
 it from dvbdev.c to dvbdev.h.



That cruft/limit comes from the old allocation. The v2.4 kernel
supported only 255 major devices with 255 minor numbers. Larger
devices have been a feature that 2.6 brought forward.

Though we have had this number incremented a while later on, we still
have some cruft in there. That limitation comes in the form of that
limitation, though if someone wants to have more devices having to
tweak MAX_DEVICES, :-/

Having limitations that way is not quite nice. That brings up the old
devfs vs udev memories
http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

2007-08-01 Thread Nick Andrew 
On Thu, Aug 02, 2007 at 03:15:04AM +0200, Janne Grunau wrote:
 Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
 result in deterministic dvb adapter numbers.

Isn't the usual response to write some udev rules to set the name
based on device characteristics?  Thus taking the naming policy
out of the module and into userspace.

Since you're defining a numbering order when you load the module, if
you have 2 or more devices which use the module then your solution
doesn't solve the problem of controlling the numbers because it
depends which device the kernel finds first. With udev, if there's
some way to distinguish between two of the same device, then rules
can be written to set the name of each.

Nick.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb