linux-kernel - RE: Disable bus's drivers_autoprobe before rootfs has mounted

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: <646601284e0347799a4e32aa10882e2b@BL2PR03MB226.namprd03.prod.outlook.com>
Date:	Fri, 13 Jun 2014 07:30:38 +0000
From:	Peter Chen <Peter.Chen@...escale.com>
To:	"balbi@...com" <balbi@...com>,
	Alan Stern <stern@...land.harvard.edu>
CC:	Greg KH <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Matt Porter <matt.porter@...aro.org>
Subject: RE: Disable bus's drivers_autoprobe before rootfs has mounted

 
> > > > I am just worried if we change the behaviour of using gadget
> > > > driver, can it be accepted by user? If you think it can be
> > > > accepted if we can have some docs, we can implement manually
> > > > binding for gadget driver from now on.
> > >
> > > user shouldn't have to deal with direct module insertion/removal
> > > (unless he's a developer and actually *wants* to do that). Docs are
> > > already in tree. The entire configfs interface has been documented,
> > > it's based on those documents that Matt started writing libusbg.
> > >
> > > --
> > > balbi
> >
> > Yes, gadget-configfs is a good direction.
> >
> > I would like to know your plan for other gadget drivers
> > (g_mass_storage, g_webcam, etc)
> 
> they can be built dynamically too. We only provided a version of
> g_mass_storage in order to avoid regressions. We can't simply remove that
> driver from the kernel.
> 
> > All functions will be supported by configfs in future, and current
> > driver will be deleted?
> 
> I don't think we will be able to delete legacy drivers, but they're all
> supported through configfs. I guess only webcam is missing.
> 
> > - If yes, how to cover the user who still use the old file system?
> > - If no, which binding way for udc and gadget driver will be used?
> 
> going forward, we want to stick with configfs.
> 

ok, then, what's the plan for current bug for legacy gadget driver (eg, we
can't load gadget driver before udc is ready)? I know this bug is existed
from 3.10, we may need to at least 1 year for switch to configfs, it
includes lots of user habit problems. The user will complaint this problem
for more than 2 years. 

If you think we should fix this bug before we totally switch to configfs, I will
continue to enhancement my gadget bus implementation,
and let it support configfs and legacy gadget driver well.

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