Q8:BËJ B<IE<C E<NJ
Total Page:16
File Type:pdf, Size:1020Kb
GIF>I8DD@E> Kernel News Q8:BËJB<IE<CE<NJ JkXkljf]?>8=iXd\Yl]]\i I\dfm`e^=`idnXi\]ifd ?\cg`e^8lkfdXk\B\ie\c ;i`m\i k_\B\ie\cKi\\ 9l`c[j The HGA Framebuffer driver is no longer David Woodhouse wants to remove all Clifford Wolf has written a new makefile maintained. Roland Kletzing confirmed third-party firmware out of the kernel target, no2modconfig. Ordinarily, when that the official maintainer, Ferenc Ba- source tree. David is in favor of letting the you configure your kernel for compila- konyi, has not had the relevant hardware kernel load arbitrary blobs of firmware tion, any option in which you type N since 2001. Thus, the MAINTAINERS code (provided the resulting binary can will not be compiled. With no2modcon- entry is completely out of date and Ro- be distributed legally under its license), fig, those items are compiled into mod- land has posted a patch to remove it. but he doesn’t think such things belong ules. Apparently, this is useful for auto- in the kernel. He’s working on creating a generating kernels. =flik_$GXikp;i`m\ij6 separate git tree for all of them. Sam Ravnborg, it turns out, has some Michael Buesch has been designing A number of replies dissented from patches that do what Clifford wants in a and building his own hardware devices this. Most folks were in favor of isolating way that uses the existing allmodconfig and recently asked whether he should firmware into a single location, but taking build target with a predetermined base submit drivers for that hardware or just it out of the tree seemed too much be- config file. In response to Clifford’s post- keep them as a separate patch. The cause it created issues of competing firm- ing, Sam said he’d try to get his own so- overwhelming response was, “Send ware packages and other requirements lution ready to be reviewed in the near in the drivers!” Apparently, as long as that some folks don’t want to tackle. future. Michael – or anyone else – is willing The most vocal opponent of David’s to document how folks can build the idea was David S. Miller, who has been Ni`k`e^Le[\i:iXd=J# hardware for themselves, the drivers for fighting against this idea for a while, spe- JhlXj_=J#Xe[Fk_\ij that hardware will be a welcome addi- cifically regarding the tg3 driver, which Arnd Bergmann added write support to tion to the kernel. With that kind of en- he felt needed to keep its firmware in the CramFS … sort of. Now the user is able couragement, hopefully we’ll start see- main tree. David Miller said that if distri- to modify files on a running system, but ing a variety of unique hardware drivers butions like Debian wanted to avoid any the files themselves are never written to appear. binary-only data in their kernel, it was up disk – the changes just hover in memory, to them to write and maintain the neces- and a reboot returns the system to its The Linux kernel sary patches out-of-tree. original state. Phillip Lougher says he’s mailing list com- David Woodhouse responded that he’d also planning to implement this sort of prises the core of already taken steps to ensure that even thing for SquashFS. Typically, past at- Linux development without removing the firmware, his tempts involved the use of UnionFS to activities. Traffic vol- changes would still be useful, but he did overlay a TmpFS instance on the filesys- umes are immense, feel it would be better to take them out tem in question. Arnd pointed out that often reaching ten entirely. At this point, folks turned the UnionFS isn’t actually the best solution thousand messages discussions into a technical consideration and that coding the feature directly into in a given week, and about how the idea might be imple- CramFS is preferable to the hackiness of keeping up to date mented. Whether some of the ideas were UnionFS. Phillip added that stackable with the entire scope of development is intended as actual suggestions or just as filesystem support really belongs in VFS, a virtually impossible task for one per- ruminations on what might be possible if which doesn’t currently support it. son. One of the few brave souls to take such a thing were desired was unclear. Enough people advocated using – or at on this task is Zack Brown. What was clear is that a lot of folks had a least fixing – UnionFS to create a techni- Our regular monthly column keeps you abreast of the latest discussions and de- variety of opinions, with many different cal discussion about how that might be cisions, selected and summarized by reasons for them. In terms of what might accomplished. Arnd and Phillip both said Zack. Zack has been publishing a weekly happen with David Woodhouse’s they’d be happy to compromise if online digest, the Kernel Traffic news- patches, I’d expect some kind of compro- UnionFS (or AUFS) could be made to do letter for over five years now. Even mise. Removing the firmware is some- what they needed without too massive an reading Kernel Traffic alone can be a thing that free software purists prefer, but effort, but the discussion ended inconclu- time consuming task. it also might be something preferable for sively. To the kernel folks, it seems clear Linux Magazine now provides you with practical, legal reasons. In that case, folks that pseudo-write support on CramFS and the quintessence of Linux Kernel activi- like David Miller could lose the battle, but SquashFS (and possibly ISO 9660 as well) ties, straight from the horse’s mouth. hopefully without too much inconve- would help users, and the features should nience being forced on them. be supported one way or another. 62 ISSUE 94 SEPTEMBER 2008 Kernel News GIF>I8DD@E> ;`i\Zk`fe]fi)%+ After what appeared to be a long hiatus, dents use 2.4 for routers, firewalls, Willy conducted the survey in part Willy Tarreau has been releasing more and other network deployment appli- to figure out how to encourage more versions of the 2.4 kernel lately. Also, cations. In those cases, upgrading to people to upgrade away from 2.4 so he’s made some effort to compile some 2.6 could be relatively easy because that tree could fade away peacefully. statistics about who uses that kernel of the few system requirements, but Willy’s main recommendation for this and why they don’t upgrade to the folks aren’t sure how to upgrade suc- was that the 2.6 folks produce a clear 2.6 kernel. With only 22 respondents, cessfully, so they just stick with what description of the functional differen- Willy’s numbers have a pretty big they know. ces between 2.4 and 2.6, so users are margin of error, but they’re still inter- Another 10 percent of respondents not left trying to figure out what is esting. About half of the folks said use 2.4 in their embedded systems prod- going to break on their own, and also they relied on 2.4 for general-purpose ucts. In this case, taking the systems that it is easily possible to go back to servers on which outages and upgrade down for an upgrade would be visible 2.4 if the upgrade doesn’t go well. regression problems would inconve- to the customer and require substantial Another reason for the survey was nience a number of people, so they changes to the company’s whole build to make adjustments to Willy’s 2.4 re- don’t bother to upgrade to 2.6 and process. lease schedule. He said, “I will issue tend to keep the latest 2.4. About 20 The rest of the respondents, appro- stable releases a bit more often for percent of the respondents use 2.4 for ximately another 10 percent, run 2.4 users to quickly get their fixes, but pro- application-specific servers, which on their personal systems, either be- gressively increase the delay between tend to be “mission critical” servers on cause they didn’t want to try to config- major releases.” He continued by say- which any outage – even upgrading to ure a new kernel for that hardware or ing that major releases would only be the most recent 2.4 kernel – would be because they were used to working on issued with new PCI IDs, major driver a big problem. the system as-is and don’t want any updates, and compiler support, for Approximately 10 percent of respon- change at all. example. C`eloDX^Xq`e\<oZclj`m\ SEPTEMBER 2008 ISSUE 94 63.