linux-kernel - Re: 3.5-rcX: USB support without udev?

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]

Date:	Sun, 1 Jul 2012 15:14:11 -0500
From:	Bob Tracy <rct@...rkin.frus.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Ming Lei <tom.leiming@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: 3.5-rcX: USB support without udev?

On Fri, Jun 29, 2012 at 11:35:19PM -0400, Greg KH wrote:
> On Thu, Jun 28, 2012 at 10:36:00PM -0500, Bob Tracy wrote:
> > On Thu, Jun 28, 2012 at 09:39:45PM +0800, Ming Lei wrote:
> > > On Thu, Jun 28, 2012 at 9:16 PM, Bob Tracy <rct@...rkin.frus.com> wrote:
> > > > With the removal of the deprecated usbfs feature in the 3.5 release
> > > > candidates, is there a way of getting USB devices working on a non-
> > > > embedded Linux system without udev (static "/dev")?
> > > 
> > > Please try to enable below options:
> > > 
> > > CONFIG_DEVTMPFS=y
> > > CONFIG_DEVTMPFS_MOUNT=y
> > > 
> > > and you need not the static dev nodes with devtmpfs.
> > 
> > It was worth a try, but it didn't help in my situation.
> 
> Why not?  What is using usbfs device nodes that can not find them in
> /dev/bus/usb/ that devtmpfs creates?

If I knew what was missing, I'd create it and be done with it.  Here's
the scenario...  Kernel built from the standard kernel.org tree.  All
drivers needed at boot time are built-in, except now there's probably
something missing on the USB side of things.  No initrd.  I'll attach my
config file on the good chance someone will spot the missing piece(s)
quickly.  Note that the DEVTMPFS options are disabled in this config,
but I'll reenable them if required.  When I said devtmpfs "didn't help,"
what I meant was, by itself relative to my current configuration, turning
on devtmpfs made no difference.

Per the syslog entries I included in my initial post on this thread, the
only difference between the pre- and post- usbfs removal cases seems to
be whatever is needed for the input subsystem to see the USB keyboard
and mouse.  I see the USB hubs and attached devices getting detected,
but whatever "glue" allows the keyboard and mouse to work isn't there,
and the input subsystem doesn't emit the expected messages at boot time.

I booted a recent Kubuntu distro on the same box and noted a few
differences as far as the /dev tree.  In particular, the modern way of
doing things has "hiddevX" directly under "/dev/usb" rather than under
"/dev/usb/hid".  There are some "by-path" and "by-id" symlinks under
"/dev/input" as well, pointing to entries in the sysfs tree.  Haven't
tried a boot yet with those differences accounted for, but plan to do
so soon.

--Bob
--
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/