linux-kernel - Re: [PATCH] Add device addition/removal notifier

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:	Fri, 20 Oct 2006 17:35:06 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Greg KH <greg@...ah.com>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, Len Brown <len.brown@...el.com>,
	Deepak Saxena <dsaxena@...xity.net>
Subject: Re: [PATCH] Add device addition/removal notifier

> Ick, I'd like to say that this is a pretty bad thing to do.  If you need
> that, then just statically link the bus into your code, or make your
> code a module and it will depend on the usb core.  I don't know...
> 
> Remember, we didn't add a type identifier to the struct device for a
> reason, comparing the string of the bus type is not a good idea (for
> USB, it will get you in trouble, because two different types of devices
> can be on that bus, who's to say other busses will not also have that
> issue?)
> 
> I think you need to re-evaluate exactly what you are needing to do
> here...

BTW. You basic saying that one should not test the bus type of a generic
struct device* makes it basically impossible to implement dma_map_* on
platforms that have various bus types with different DMA operations :)

Note that what I'm working on at the moment might make all of that
easier anyway, by having (on powerpc only for now but some of that could
be made generic once I'm finished) dma_ops having off the struct device
(or rather an extension of it).

Oh, also, right now, I re-use the firmware_data pointer there to point
to my struct device_ext, but I'd like to be better typed and avoid too
many pointer dereferences. I'm thus thinking instead of defining an
asm-*/device.h where archs can define their own struct device_ext and
have that flat in struct device (default being an empty struct). We
could even get rid of firmware_data on archs that don't use it by
putting it there :) (Among others).

Ben.

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