[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C517D80.6010106@gmail.com>
Date: Thu, 29 Jul 2010 15:09:20 +0200
From: Jiri Slaby <jirislaby@...il.com>
To: H Hartley Sweeten <hartleys@...ionengravers.com>
CC: Linux Kernel <linux-kernel@...r.kernel.org>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
"ss@....gov.au" <ss@....gov.au>, "gregkh@...e.de" <gregkh@...e.de>
Subject: Re: [PATCH] Staging: dt3155: properly export the module parameter
On 07/29/2010 02:55 AM, H Hartley Sweeten wrote:
> On Wednesday, July 28, 2010 1:59 PM, Jiri Slaby wrote:
>> On 07/28/2010 06:48 PM, H Hartley Sweeten wrote:
>>> --- a/drivers/staging/dt3155/dt3155_drv.c
>>> +++ b/drivers/staging/dt3155/dt3155_drv.c
>>> @@ -99,7 +99,9 @@ wait_queue_head_t dt3155_read_wait_queue[MAXBOARDS];
>>>
>>> /* set to dynamicaly allocate, but it is tunable: */
>>> /* insmod DT_3155 dt3155 dt3155_major=XX */
>>> -int dt3155_major = 0;
>>> +static int dt3155_major;
>>> +module_param(dt3155_major, int, 0);
>>> +MODULE_PARM_DESC(dt3155_major, "Major device number");
>>
>> Is it necessary in the age of udev?
>>
>> I would personally get rid of that completely...
>
> I agree but I'm not quite sure if the user space app is ready to handle that.
Given it was never exposed as a parameter, applications should handle
that. 0 means allocate major dynamically...
regards,
--
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists