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
| ||
|
Date: Mon, 20 Nov 2006 23:54:31 -0800 From: Greg KH <gregkh@...e.de> To: Paul Sokolovsky <pmiscml@...il.com> Cc: Arjan van de Ven <arjan@...radead.org>, Jiri Slaby <jirislaby@...il.com>, linux-kernel@...r.kernel.org, Adrian Bunk <bunk@...sta.de>, kernel-discuss@...dhelds.org Subject: Re: Where did find_bus() go in 2.6.18? On Mon, Nov 20, 2006 at 04:13:22PM +0200, Paul Sokolovsky wrote: > Hello Greg, > > Monday, November 20, 2006, 2:12:12 AM, you wrote: > > > On Mon, Nov 20, 2006 at 12:45:51AM +0100, Jiri Slaby wrote: > >> Paul Sokolovsky wrote: > >> > But alas, the commit message is not as good as some others are, and > >> > doesn't mention what should be used instead. So, if find_bus() is > >> > "unused", what should be used instead? > >> > >> You should probably mention what for? > > > Exactly. It was removed because no one was using it, and I couldn't > > think of a reason why it would be needed. > > So, I assume the answer to my question is "No replacement. Ability > to query bus set in the kernel was just removed, period." That's to > which conclusion I came myself after studying 2.6.18 source and patch > from 2.6.17. Yes, it was removed because no one was using it, and no one could think of any reason why it would be needed at the time. > [Uninteresting specific case] > > Ok, so the situation is following: we have a kind of multi-layered > driver here. Lowest level is a w1_slave bus driver, talking to a > specific chip and providing low-level API for accessing data in terms > of this chip (or chip class) notions. Above it, we have higher-level > driver which interprets data from the low-level one, converting it to > a standard device-independent form, plus possibly does some other > minor things, like providing feedback indication on these data. > (Forgot to say that this is battery driver.) > > So, just in case if some reader of this has quick suggestion of > merging these drivers into one, thanks, but they do different things, > and we want to keep them nicely decoupled. But now issue of how these > drivers talk between themselves raises, and that's exactly the grief > point. > > High-level driver used to find w1 bus by name, then enumerate > devices on the bus, to find compatible device on it, then hooks into > that device and its driver. Ick, why not just export the pointer to the devices? > So, you see the issue: we cannot enumerate devices on w1 bus. (And > yes, w1_bus_type is not exported). > > Sure, the source is up: > http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/misc/h2200_battery.c?rev=1.20&content-type=text/x-cvsweb-markup > > > [Trends thoughts] > > But note that I don't really ask mainline kernel developers how to > fix this driver - I would actually be ashamed to do so, as I myself a > (newbie) kernel hacker. So, the question stays the same, though I > probably reformulate it a bit stronger now: how it came that ability > to query buses (at all) was removed from 2.6.18? See above. > As it was before, it was clear that LDM consists of multiple layers, > and each layer offers consistent and complete set of operations on it, > like adding new object on this layer, removing, adding child, removing > child, *and* query objects on this level or among childs. I may miss > some accidental gaps in that picture of course, but it still was an > integral, complete design paradigm offering full dynamicity and > introspection. Hm, I've never heard the driver model be called a "complete design paradigm" in the past. I've heard it called a lot of real nasty things though :) > And suddenly - oops, in 2.6.18 we lose ability to query the highest > level of hierarchy, namely bus set. And on what criterion? "unused". <snip> Please go read Documenation/stable_api_nonsense.txt for why the in-kernel apis always change. It's how Linux works. > Suddenly, concrete building of LDM appears to be shaking. And reasonable > question here is: is this a trend? What we will lose next - ability to > query/enumerate devices on bus? How much time it will take until > someone submit patch like "You know, I had a look at this > device vs drivers matching in LDM. You know, I found that in 90% it's > one-to-one mapping. You know, I think that rest 10% are just doing > something wrong. You know, let's don't care about them. Here's a > patch to match compile-time by C symbols. Oh no, wait, I have a patch > in preparation which kills device vs drivers distinction at all, > leading us to ol' good dirty monolithic 'drivers'." And it may be the > case that even designers of LDM will look at the code after all > those previous "cleanups" applied, and would agree that such patch > comes as pretty natural succession. It might just come to that if things evolve that way, who really knows. > Thanks for following my mental movie ;-). It's not a pure rhetoric > though, I indeed would like to know the answer - are all those > structures in LDM are big guys' games only? And would it better for small > guys to be as KISS as stupid, err..., possible? ;-) Please, get your code into the main kernel tree so that we can see it and know how the driver core is being used. > > Also, any reason why your drivers aren't in the mainline kernel yet? It > > would have kept something like this from happening a while ago. And, it > > will also help out with the recent driver core changes that are being > > planned and are starting to show up in the -mm tree. If your stuff is > > in the kernel, then I'll do the work for you, otherwise, you all are on > > your own :( > > One reason is of course because it's not that easy to get something > into mainline. ;-) Why do you feel this way? Is it a proceedural thing? A technical thing? A time thing? We want to make it as easy as possible to get code into the tree, please submit it and be persistant to get it there. > Another one is that we have great deal of code made by > different people over different periods of time, and we need to do > internal cleanup first. That's the way the kernel works, nothing new here. > And for example, as new people do it, and > learn the entire codebase, they find that some things are done, > well, so to say, above the ground level. And they start to worry if > that was right in the first place, and would it be now possible to get > this somebody's code into mainline, or its better to keep doing > homework and reapply the KISS paradigm. It is also a bit of ethical > problem, as gentlemen who made such implementations, were apparently > experienced developers to come up with such solutions, but no longer > around/have resources to lobby for such code themselves, and newcomers > would likely get only frustration from trying to do that, especially > if they see there *is* at least an abstract possibility to do it in > some other, more mundane way. And yet they can't readily do that local > paradigm shift, as well, they don't have enough experience to undo > what gurus did previously, plus the whole Linux-on-PDA community is > too short on people to spend time flip-flopping each other's work. Evolve things over time in the main tree, like the main tree works. Again, this is nothing different from the rest of the kernel. > All above has little to do with mainline kernel, of course, and not > its problem in any way. Just another entry into your sociological > survey "Why people don't submit code upstream." ;-) No, I really think you are somehow feeling that once the code is in mainline it can't be ever changed. That's just not true... thanks, greg k-h - 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