Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Anyone who programs ATA controllers on the basis of common sense
rather than documentation, errata sheets and actually testing
rather than speculating is naïve.
-- Alan Cox
I'm invoking the anti-discrimination statutes here on behalf of
those of us who don't like beer.
-- James Bottomley pushes the limits of
tolerance
Realize that 50% of today's professional programmers have never
written a line of code that had to be compiled.
-- Casey Schaufler
As you can see in these posts, Ralink is sending patches for the
upstream rt2x00 driver for their new chipsets, and not just dumping
a huge, stand-alone tarball driver on the community, as they have
done in the past. This shows a huge willingness to learn how to
deal with the kernel community, and they should be strongly
encouraged and praised for this major change in attitude.
-- Greg
Kroah-Hartman
There are no "rules", things have to work and that is the only rule.
-- Markus Rechberger (context here)
(Log in to post comments)
...wow. Posted Feb 10, 2011 13:43 UTC (Thu) by cesarb (subscriber, #6266) [Link]
That kind of abuse (injecting a shared library on EVERY process in the system) is something I thought I would only ever see on Windows. I have read horror stories where installing badly written drivers for some devices injected a DLL on every process, causing very mysterious crashes. It is also a malware technique, one which makes them very hard to remove (to the point where the "Linux Live CD" method is the only option).
It makes me sad to see this kind of thing starting to happen. Perhaps Linux is getting TOO popular. I hope we can manage to avoid the sort of polluted ecosystem we see on Windows, where each program does what it wants with no regard to the well-being of the overall system.
...wow. Posted Feb 10, 2011 14:04 UTC (Thu) by cesarb (subscriber, #6266) [Link]
And reading the thread, I can see it is *even worse* than I thought.
> it only intercepts calls to /dev/videoN, /dev/radioN, /dev/dspN, /dev/dvb, everything else will go straight to a syscall eg. syscall(SYS_open, __file, __oflag, mode);
-- http://lists.samba.org/archive/samba-technical/2011-Febru...
That is, instead of the normal behavior for preloaded libraries (using RTLD_NEXT to pass on to the next library, as on my https://github.com/cesarb/glxswapbuffersmeasure), they are BYPASSING glibc entirely. This will completely bypass any extra handling glibc could have on open().
And even more interesting, them calling the kernel directly means they will NOT play nice with others using the same technique (preload) they are using! I have to mention Raymond Chen's post on the subject: "What if two programs did this?" (http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/42...).
Not only are they doing the wrong thing, they are also doing it wrong.
...wow. Posted Feb 10, 2011 14:28 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> This will completely bypass any extra handling glibc could have on open().
And it probably does have extra handling. A quick look at the glibc source code for open64() (at sysdeps/unix/sysv/linux/open64.c) shows, for instance, pthread cancellation point handling.
Don't like beer Posted Feb 10, 2011 14:08 UTC (Thu) by Seegras (subscriber, #20463) [Link]
.. is of course not understandable. There's hundreds of different kinds of beer, and it's highly unlikely that there exists a person on earth which really does not like at least one of those.
Of course, if you only know Bud/Coors/Millers light, then there's at least an explanation. On the other hand, those are not "beer", except in a technical sense.
Don't like beer Posted Feb 10, 2011 23:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Easy. There are persons on Earth (me included) who do not like anything alcoholic.
I've tried non-alcoholic beer, but meh..
Don't like beer Posted Feb 11, 2011 11:21 UTC (Fri) by mpr22 (subscriber, #60784) [Link] Someone with gluten intolerance and a dislike of bitter things is unlikely to find a beer they both (a) want to drink (b) want to have drunk. (Note: I like beer.)
Don't like beer Posted Feb 12, 2011 0:38 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] I know someone who becomes violently ill from even small amounts of alcohol, like one sip from a mixed drink. I doubt there's any beer that she likes. I know other people who have religious objections to alcohol, and I'm sure they're in the same boat.
Quotes of the week Posted Feb 10, 2011 19:51 UTC (Thu) by mb (subscriber, #50428) [Link]
Wow. That preload thing is one of the worst hacks I ever saw. He calls it a driver. I call it a dirty hack.
Quotes of the week Posted Feb 10, 2011 23:26 UTC (Thu) by PaulWay (✭ supporter ✭, #45600) [Link]
My suspicion here is that Markus is a really clever guy, but he has no other clever people to talk to. So everyone around him is 'dumb', and therefore everyone else who doesn't get how he deals with things is also 'dumb' by definition.
I suspect that he's now going to find a whole community of really smart people who are also going to get really angry with his attitude. One group is going to give in on this, and it's not going to be the rest of the Linux using developers.
Personally I'm waiting for the point at which Markus says "so what, what has this tridge guy written that's any good?" Because that's going to be hilarious.
Have fun,
Paul
Quotes of the week Posted Feb 10, 2011 23:31 UTC (Thu) by corbet (editor, #1) [Link] For what it's worth, this is not his first encounter with the community; he has a lot of changes in the mainline. It hasn't always gone smoothly, though.
Quotes of the week Posted Feb 10, 2011 23:24 UTC (Thu) by sb (subscriber, #191) [Link]
That preload kludge is just unbelievable!
To ship this thing to users, and then defend it against all technical arguments saying "meh, it works for us", shows monumentally poor taste. I wouldn't want that guy's software anywhere near my machines and will be sure to stay away from any hardware that he's writing "drivers" for.
This is typical impedance mismatch... Posted Feb 11, 2011 0:23 UTC (Fri) by khim (subscriber, #9252) [Link] Actually this will mean you should stop using any appliances at all. Markus is quite typical embedded guy. If you'll take a look on Android case you'll see similar problems. The summary of the problem is quite simple: "Working driver should be submitted to the repo by 12:00 of January 1st - EOM". The date is arbitrary, the attitude is not. When you are developing in embedded space the manufacturing issues take priority. Your software must be ready by certain time. You literally don't have the luxury of developing nice interfaces and passing community review. But at some point you need/want to submit the driver upstream - this is where TSHTF: kernel developers insist on clean interfaces and tend to ignore manufacturing issues completely. This is understandable: this is not their problem. But this leaves noone who can properly support the device! The in-company developer is prisoner to release schedule and tight deadlines while community at large does not have enough information to support the driver! Public information is not enough: often you need access to the chip errata to fix problems, etc.
This is typical impedance mismatch... Posted Feb 14, 2011 11:56 UTC (Mon) by mb (subscriber, #50428) [Link]
Yes, but who's to solve that problem?
The community, by accepting incredibly hackish patches/drivers? Or the company by changing their workflow and attitude towards good software?
In the long term, hackish patches/drivers will cause _major_ pain and hurt the overall project. (Just imagine there were two "drivers" doing markus' particular hack.) So accepting them is not an option.
In the long run we are all dead. Posted Feb 14, 2011 23:34 UTC (Mon) by khim (subscriber, #9252) [Link] So... there are no simple solution for the problem. To accept the community demands is to kill the product: compare Maemo's fate and Android fate. To accept the hackish patches/drivers is to accept the maintenance burden so it's not a good deal for the community. What does it mean? The community expectations that companies will change their workflow are misleading. Only some companies have a luxury of doing so: most companies which tried to do so are dead, only market leaders who can afford to lose time and survive can realistically do that. And when someone preempts them they are dead too (again: Maemo vs Android). What is the solution? It's easy: if the product is not important enough then keep it out of trunk. If it is important enough then community must deal with it... somehow. Just don't expect it to be an easy fight: push on the company and it'll fold up. Nope: companies do simple analysis of prices for different solutions and only change when it makes sense from economic POV. If the community does the heavy lifting and provides some kind of generic interface which can be adopted then companies usually accept it, but if they are pushed to develop such interface and bring it up to community standards... they usually pass. Think WiFi drivers here. Basically the rules are simple: s/he, who writes the code makes the rules. If the community does not like what company provides - it may ignore the company (which usually leads nowhere because clueless people who only want working thing always outnumber geeks - but then if the equipment is specialized enough it's not a big deal) or it can provide an alternative.
pair escape? :) Posted Feb 18, 2011 13:17 UTC (Fri) by gvy (guest, #11981) [Link]
> The in-company developer is prisoner
I've seen such things tackled in two heads: one person is hurrying up to have at least something and the other does it right.
|
|||||||||||||