linux-kernel - Re: [PATCH] driver core: multithreaded device matching with dependency

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: <466AD638.9030409@s5r6.in-berlin.de>
Date:	Sat, 09 Jun 2007 18:32:56 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	"Huang, Ying" <ying.huang@...el.com>
CC:	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>
Subject: Re: [PATCH] driver core: multithreaded device matching with dependency

Huang, Ying wrote:
> Can this mechanism solve the demand of IEEE1394 subsystem effectively?

Probably.  I don't know when I will have time to try it.

(BTW, we should actually be able to probe subunits in parallel, however
I suspect that some firmwares will not tolerate this.)

...
> +/**
> + *	device_match_thaw - renable device/driver matching and check all
> + *	pending device/driver matching.

This has to be a single line.

> + *	@thread: number of threads to do device/driver matching.
> + *
> + *	All devices are checked for driver matching, multithreaded

...
> +EXPORT_SYMBOL_GPL(device_match_freeze);
> +EXPORT_SYMBOL_GPL(device_match_thaw);

I don't know, perhaps names like "device_driver_matching_disable" and
"device_driver_matching_enable" would be more to the point.  Or do you
actually "freeze" (i.e. halt) ongoing driver probes?

> Index: linux-2.6.22-rc4/include/linux/device.h
> ===================================================================
> --- linux-2.6.22-rc4.orig/include/linux/device.h	2007-06-08
> 18:26:11.000000000 +0800
> +++ linux-2.6.22-rc4/include/linux/device.h	2007-06-09
> 19:41:03.000000000 +0800
> @@ -413,12 +413,17 @@
>  	struct klist_node	knode_driver;
>  	struct klist_node	knode_bus;
>  	struct device		*parent;
> +	struct device		*depend;

Is this core-internal now?  If not, add a comment what it does and how
it has to be written and read.

I'm curious how this has to be used; perhaps it will turn out that the
whole thing is over-engineered this way.  I.e. there might be easier
options like:
  - Let subsystems which don't want multithreaded probing at all
    disable multithreaded probing globally by a susbsystem flag.
    (Or rather, let subsystems which want multithreaded probing
    enable it globally by a subsystem flag. IOW make singlethreaded
    probing the default.  Multithreaded probing has to be tested
    thoroughly for each subsystem.)
  - Let subsystems which want only partially multithreaded probing
    serialize the necessary regions on their own by subsystem-internal
    mutexes.

However, this really depends on what the actual cost of dev->depend is.

>  	struct kobject kobj;
>  	char	bus_id[BUS_ID_SIZE];	/* position on parent bus */
>  	struct device_type	*type;
>  	unsigned		is_registered:1;
>  	unsigned		uevent_suppress:1;
> +	unsigned		is_matched:1;
> +	unsigned		is_checking:1;
> +	unsigned		is_checked:1;
> +	unsigned		singlethreaded_probe:1;
...

Ditto here:  Which of these belong to the public API?  Those flags which
are not private to the core need to be commented.

PS:  There is also a kerneldoc format for structs.  It also allows to
mark private struct members, i.e. those which do not belong to the API.
See Documentation/kernel-doc-nano-HOWTO.txt.

PPS:  Sadly, the whole struct device and some other driver core API
items lack kerneldocs.  It's ironic that the deprecated class_device is
the only drivercore struct which comes with a kerneldoc.
-- 
Stefan Richter
-=====-=-=== -==- -=--=
http://arcgraph.de/sr/
-
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/