lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AlnE4cF3jFB@christoph>
Date:	13 Sep 2008 09:21:00 +0200
From:	lirc@...telmus.de (Christoph Bartelmus)
To:	jwilson@...hat.com
Cc:	superm1@...ntu.com
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure

Hi Jarod,

on 11 Sep 08 at 15:09, Jarod Wilson wrote:
> On Thursday 11 September 2008 14:30:00 Christoph Bartelmus wrote:
>> on 09 Sep 08 at 13:03, Jarod Wilson wrote:
>>> On Tuesday 09 September 2008 03:40:18 Sebastian Siewior wrote:
>>>>>+EXTRA_CFLAGS =-DIRCTL_DEV_MAJOR=61 -DLIRC_SERIAL_TRANSMITTER -I$(src)
>>>>
>>>> Do you rely on this specific major? Since your daemon opens /dev/lirc0
>>>> you don't need a fixed major do you?
>>>
>>> Good question. Quite honestly, I'm not sure. Christoph?
>>
>> LIRC does not rely on a specific major. But to be honest, the last time I
>> looked into this issue, was when devfs was bleeding-edge...
>>
>> So, we need some advice here how to proceed. Should we try to register an
>> official major number for LIRC? Should we try to have a minor number
>> mapping, e.g.
>> /dev/lirc/serial/0 LIRC device on 1st UART serial port
>> ...
>> /dev/lirc/serial/n LIRC device on n-th UART serial port
>> /dev/lirc/parallel/0 LIRC device on 1st parallel port
>> ...
>> /dev/lirc/parallel/n LIRC device on n-th parallel port
>> /dev/lirc/usb/0 1st LIRC USB device
>> ...

> Janne took a crack at dynamic device allocation earlier today, committed
> into my git tree:

The problem is this:
http://www.lirc.org/html/configure.html#multiple

Quoting the very last paragraph:
"The only situation where the described procedure will not work is when  
you have two devices that both use a kernel driver that can only handle  
one device at once like e.g. lirc_serial, lirc_sir or lirc_parallel. You  
can still make it work with a trick by compiling the affected driver  
multiple times using different names and different major numbers. You will  
find detailed instructions how to achieve this by searching the mailing  
list. Lifting this limitation is one of the todo items for future  
releases."

The limitation that lirc_serial can only handle one device at a time still  
exists and I think we should have a concept how to solve it before the  
drivers are merged into the kernel.

Christoph
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ