Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/27/2016 08:36 PM, Mark Brown wrote: Personally the way I parse this situation is that the kernel is taking a look at what's in the DT and making an effort to present it usefully in the running systems. Fixing our current interpretation in stone as a supported thing when we don't have to makes it more cumbersome to improve and discourages any efforts to do similar things in the future. It is reasonable to provide and document something here but when there's some fairly simple and obvious better things we could be doing it should be those rather than the legacy stuff. So what are the "simple and obvious better things" that one can use instead? /Christer -- Have laptop, will travel. I'm a consultant looking for interesting jobs anywhere in the world. I'm an experienced software engineer with a solid understanding of hardware. Specialities: Linux, device drivers and embedded systems in general. Find me at www.weinigel.se.
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/26/2016 08:47 PM, Mark Brown wrote: > On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote: > >> One of the main drivers behind devicetree was that Linus got fed >> up with the churn for all platform device changes in arch/arm. >> I faintly recall him writing that he would be rather unhappy if >> that just got replaced with churn for devicetree dts files. > > Since device trees are hardware descriptions they really shouldn't > be churning at all - if they are that's an indication that we're > failing at device tree. I meant churn from the sheer number of platforms. According to gsmarena.com there were over 600 new Android devices released last year. Each and every one of them is a Linux platform. I've personally worked on *counts on fingers* 8 different custom Linux platforms during the last year. That's a lot of new device tree files if all of them were to end up in the mainline kernel. My point is that I don't think it would be doable to get every devicetree file out there into the mainline kernel; it's not even desirable. devicetree files for custom platforms are a lot like userspace applications, the devicetree implementation is an ABI, and devicetrees for a lot of different platforms are built for that ABI. Using "the dts file is not in mainline" or "there is no user of that devicetree feature in mainline" as an argument for breaking existing dts files is in my opinion not a good argument. That will be a change that is visible to userspace (because device names will change). >> For platforms based on a FPGA such as the Xilinx Zync it's even >> more pointless to submit dts files to mainline. When you have >> "hardware" that can be reconfigured the device tree files can't >> be set in stone. If I use Xilinx tools [1] to add one more UART >> I have just added new hardware this needs to be reflected in the >> devicetree for the devices to be usable in Linux. And something >> like aliases which provides a stable device name can be very >> useful here. > > Right, but it doesn't follow that aliases are what we should be > doing here - both Rob and myself have mentioned providing a way to > label the actual SPI devices themselves, this seems like a more > robust way of doing things. That would be good. It would probably be clearer to have "i2c-sensors" than "i2c3". But it won't solve all of the issues that were flagged as bad with aliases. For example, someone mentioned that even if aliases worked with devicetree fragments there could be collisions in the numbering f aliases. As long as user assigned names are used there are going to be mistakes and collisions are going to happen. Some nut like me will come along and build lots of temperature sensors and have multiple buses to talk to them, and then you end up with half a dozen "i2c-sensors" busses :-) http://zoo.weinigel.se/misc/temp-chain.jpg These are actually dallas one-wire sensors, but you get the point. The only way to guarantee uniqueness would be to use uuids or something inherently unique like bus addresses (where collisions would break other things anyway) , but then we're back to things not being that user friendly again. > Just numbering the buses provides a partial solution for some > systems with usability drawbacks (you need to know the number to > name mapping somehow), naming devices is both more direct and more > general. Except that being able to assign static bus numbers devicetree is something that works _now_ and at least for me it is good enough. Being able to assign bus numbers makes life for me and the colleagues I have to support a lot easier. The whole reason I started looking at assigning bus numbers to spi ports was a very frustrated colleague complaining about the seemingly random bus number assignment. To be able to put stickers on the pin headers on a board saying "spi1", "spi2" and "spi3" and being able to refer to those numbers in in an email makes things a lot easier. It would probably be better if some future devicetree extension would allow abitrary user-friendly naming of devices, but in the absence of that I'd take numbers every time. If I'd have to wait for a perfect solution before doing something I'd never get anything done. A dumb and ok solution is often "better" than a complex one. /Christer
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/26/2016 12:07 PM, Mark Brown wrote: > I think Rob's referring to the fact that there are no in tree DTs > that use this feature - all the aliases for SPI controllers in > mainline are string based. One of the main drivers behind devicetree was that Linus got fed up with the churn for all platform device changes in arch/arm. I faintly recall him writing that he would be rather unhappy if that just got replaced with churn for devicetree dts files. It makes sense to include dts files for reference boards in the mainline kernel. To include dts files for every vendors variant of a design would add just as much churn and be rather pointless. My guess is that the dts file for most platforms are kept private. For platforms based on a FPGA such as the Xilinx Zync it's even more pointless to submit dts files to mainline. When you have "hardware" that can be reconfigured the device tree files can't be set in stone. If I use Xilinx tools [1] to add one more UART I have just added new hardware this needs to be reflected in the devicetree for the devices to be usable in Linux. And something like aliases which provides a stable device name can be very useful here. /Christer [1] http://www.wiki.xilinx.com/Build+Device+Tree+Blob
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/26/2016 03:44 AM, Rob Herring wrote: Lovely. "Here's something that's simple and useful for users. Let's break it". What part of "we do not break userspace" do you not understand? Because that would be a user visible change. The other saying is "if it is not upstream, it doesn't exist." That said, I don't think we should remove it. Maybe some time later, but first we need a suitable alternative. Huh? Commit bb29785e0d6d, which added support for assigning spi bus numbers via devicetree aliases, has been in the upstream Linux kernel since v3.9 which was released over three years ago. /Christer -- Have laptop, will travel. I'm a consultant looking for interesting jobs anywhere in the world. I'm an experienced software engineer with a solid understanding of hardware. Specialities: Linux, device drivers and embedded systems in general. Find me at www.weinigel.se.
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/25/2016 08:44 PM, Mark Brown wrote: > On Wed, May 25, 2016 at 11:06:46AM -0700, Frank Rowand wrote: >> On 5/25/2016 10:49 AM, Rob Herring wrote: > >>> Things get undocumented all the time when we deprecate them. > >> If it is deprecated then it should be documented as deprecated >> so people do not attempt to use it. > > Or we could just remove the code, we don't appear to have any in > tree users anyway (the few in tree aliases for SPI buses I can see > are string based). Lovely. "Here's something that's simple and useful for users. Let's break it". What part of "we do not break userspace" do you not understand? Because that would be a user visible change. /Christer
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/25/2016 12:38 PM, Mark Brown wrote: > On Wed, May 25, 2016 at 10:20:34AM +0100, Mark Rutland wrote: >> On Tue, May 24, 2016 at 01:41:26PM -0700, Frank Rowand wrote: > >>> The code and behavior is in the Linux kernel. It should be >>> visible in the documentation instead of being a big mystery of >>> how it works. > >> As above, I don't entirely agree. Mindlessly documenting existing >> Linux behaviour can have the unfortuante effect of moving people >> towards the wrong tool for the job. > > Yes, this is exactly my concern - the articulated use case (which > didn't suprise me at all) is for using spidev which is itself not > just Linux specific but this particular version of Linux right now > specific. There are lots of things that happen to work but are in > fact terrible ideas that leave messes for our future selves. We > need to distinguish between things that are real, meaningful system > descriptions and things that are implementation details resulting > from the rush to force everyone on to DT. Oh, for *beep* *beep* sake. It used to be very easy to use SPI devices on Linux with stable device names. Add a platform device entry and set bus_num. Add spidev entries specifying the chip select, mode, speed and other specifics for the devices on the bus. Then just use /dev/spi$bus_num.$chip_select to talk to them. Very simple to use and understand. Doing the same with devicetree ought to be just as simple, and since Grant added that patch it actually is. The behaviour is already in the Linux kernel. Nobody is going to rip out the of_alias_get_id usage from the spi driver sice that will break existing userspace. Nobody is going to rip out the spidev framework from the Linux kernel. The aliases mechanism which is specifically intended to provide easy-to use names for userspace. From "A Symphony of Flavours: Using the device tree to describe embedded hardware" by Grant Likely and Josh Boyer: In order to ease device lookup in client operating systems, it is often desirable to define an aliases node. This allows one to provide a shorthand method for identifying a device without having to specify the full path on lookup. What is so horrible about documenting the actual behaviour of the Linux kernel? How is documenting that serial0 = /amba@0/blah@blah" which is ok, so markedly different from documenting spi0 = "/amba@0/blah/blah"? Does everything have to be so damn difficult? Ignore the patch if you want to, I give up. I just hope that someone else that needs to do the same thing will find my patch with this (ought to be) trivial documentation. /Christer (tired of bikeshedding)
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/24/2016 08:32 PM, Mark Brown wrote: > On Tue, May 24, 2016 at 08:03:48PM +0200, Christer Weinigel wrote: >> On 05/24/2016 07:20 PM, Mark Brown wrote: > >>> I'm not sure this is something we want to support at all, I >>> can't immediately see anything that does this deliberately in >>> the SPI code and obviously the "bus number" is something of a >>> Linux specific concept which would need some explanation if we >>> were going to document it. It's something I'm struggling a bit >>> to see a robust use case for that isn't better served by >>> parsing sysfs, what's the goal here? > >> If this isn't something that should be in the >> Documentation/devicetree because it's not generig enough, where >> should Linux-specific interpretations such as this be >> documented? > > I'm not clear that we want to document this at all since I am not > clear that there is a sensible use case for doing it. I did ask > for one but you've not articulated one in this reply. I am much > less gung ho than Grant on this one, even as a Linux specific > interface it seems very legacy. It's bloody convenient. I'm working with a Zync board right now where we have multiple SPI ports. Being able to label the ports on the board spi1, spi2 and spi3 and having spidev devices show up as /dev/spidev1.0 instead of dynamic assignment makes things much easier. Especially when doing driver development where unloading and reloading the spi driver module will give it a new dynamic number every time. Yes, it's possible to iterate through all files /sys/class/spi_master and then have a table to map those names to device names and create symlinks to them, it's just painful. It's much easier to do be able to do "cat data >/dev/spidev1.0" from busybox and not have to set up all that infrastructure. And yes, this is on an embedded system using busybox without udev. In addition, right now I have a couple of different variants of the boards that I work on, and with different SPI ports at different addresses. It's rather nice to be able to reuse the same kernel + ramdisk on multiple variants and only have to update the devicetree to get sensible devices names on all variants. /Christer
Re: [PATCH] devicetree - document using aliases to set spi bus number.
On 05/24/2016 07:20 PM, Mark Brown wrote: >> Not having used devicetree that much it was surprisingly hard to >> figure out how to assign a stable bus number to a spi bus. Add >> a simple example that shows how to do that. > > I'm not sure this is something we want to support at all, I can't > immediately see anything that does this deliberately in the SPI > code and obviously the "bus number" is something of a Linux > specific concept which would need some explanation if we were going > to document it. It's something I'm struggling a bit to see a > robust use case for that isn't better served by parsing sysfs, > what's the goal here? Well, that's how it works right now: commit bb29785e0d6d150181704be2efcc3141044625e2 Author: Grant Likely Date: Fri Dec 21 19:32:09 2012 + spi/of: Use DT aliases for assigning bus number > + if ((master->bus_num < 0) && master->dev.of_node) + > master->bus_num = of_alias_get_id(master->dev.of_node, "spi"); If this isn't something that should be in the Documentation/devicetree because it's not generig enough, where should Linux-specific interpretations such as this be documented? /Christer
[PATCH] devicetree - document using aliases to set spi bus number.
Document how to use devicetree aliases to assign a stable
bus number to a spi bus.
Signed-off-by: Christer Weinigel
---
Trivial documentation change.
Not having used devicetree that much it was surprisingly hard to
figure out how to assign a stable bus number to a spi bus. Add a
simple example that shows how to do that.
Mark Cced as the SPI maintainer. Or should trivial documentation
fixes like this be addressed to someone else?
/Christer
Documentation/devicetree/bindings/spi/spi-bus.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt
b/Documentation/devicetree/bindings/spi/spi-bus.txt
index 42d5954..c35c4c2 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -94,3 +94,13 @@ SPI example for an MPC5200 SPI bus:
reg = <1>;
};
};
+
+Normally SPI buses are assigned dynamic bus numbers starting at 32766
+and counting downwards. It is possible to assign the bus number
+statically using devicetee aliases. For example, on the MPC5200 the
+"spi@f00" device above is connected to the "soc" bus. To set its
+bus_num to 1 add an aliases entry like this:
+
+ aliases {
+ spi1 = "/soc/spi@f00";
+ };
--
1.9.1
Re: [PATCH 08/24] net, diet: Make TCP metrics optional
On 2014-05-07 15:35, One Thousand Gnomes wrote: > IoT devices don't care. Most embedded devices don't care. A lot of the > current generation of proprietary non Linux very low end RTOS systems > support *one socket*, some even use a wireless controller which has a > proprietary mini tcp/ip and wifi stack that provices *one socket* > > If you want Linux to run on the kind of low end 'single chip' systems or > FPGA systems then you want to be able to run in very little memory. > Network performance is usually near irrelevant. If its controlling a > smart plug it doesn't need to do megabit encrypted streams or fast > connect. > This describes an industrial control system I've been working on for the last ten years or so. It runs one application, this application makes one single TCP connection to a server which then stays up forever. The server can send modified configuration to the application and the application sends periodic reports about what it is doing. We've replaced 9600 bps current loop with TCP, not for performance reasons but for convenience. We have no use for ethtool, no use for packet filters, no use for firewalling and don't care if a socket uses 100 bytes or 10kBytes of kernel memory since we only have one. There are probably lots of embedded systems that need those features, but there are also lots of systems that don't. The first version of the hardware used a 2.4.26 kernel on an Axis ETRAX LX processor, now were using a 2.6.33 kernel on an Atmel ARM9 processor. We have a problem with the flash getting corrupted every now and then, and this seems to be fixed in the latest stable kernel (3.10). There are about 2000 changes to drivers/mtd and so far we have not been able to bisect this to find out where and why things started working. So we'd like to upgrade but we are also starting to run short on flash and the 3.10 kernel is noticeably bigger with the same configuration. Switching from gzip to xz compression did give us back enough flash space to fit everything in, but it's still tight. So if we can save a couple of 100k of text size and get a slightly less performant or featureful TCP stack, that would be a very good tradeoff for us. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] Update coding standard to avoid ungrepable printk format strings
Andi Kleen wrote:
RFC: Update coding standard to avoid split up printk format strings
While we're talking about checkpatch.pl, I'd definitely like to teach
checkpatch about "list_for_each" and friends.
list_for_each is flow control, not a function call. I find it much
easier to see that something is a loop when there is a space between the
name and the parenthesis rather than when they are smashed together.
old patch follows
/Christer
checkpatch complains about the following:
WARNING: no space between function name and open parenthesis '('
#520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
+ list_for_each_entry (transfer, &message->transfers, transfer_list) {
which I think is a bit bogus since it actually is a for statement in
disguise. The following patch adds list_for_each to the list of things
that look like functions that it shouldn't complain about.
Index: linux-2.6.23/scripts/checkpatch.pl
===
--- linux-2.6.23.orig/scripts/checkpatch.pl
+++ linux-2.6.23/scripts/checkpatch.pl
@@ -681,7 +681,7 @@ sub process {
# check for spaces between functions and their parentheses.
if ($line =~ /($Ident)\s+\(/ &&
- $1 !~
/^(?:if|for|while|switch|return|volatile|__volatile__|__attribute__|format|__extension__|Copyright)$/
&&
+ $1 !~
/^(?:if|for|while|switch|list_for_each.*|return|volatile|__volatile__|__attribute__|format|__extension__|Copyright)$/
&&
$line !~ /$Type\s+\(/ && $line !~ /^.\#\s*define\b/) {
WARN("no space between function name and open parenthesis '('\n" .
$herecurr);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sat, 9 Feb 2008 17:41:00 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote: > On Feb 9, 2008 5:13 PM, Christer Weinigel <[EMAIL PROTECTED]> > wrote: > > But lets say that the b-tree code uses Linux-only primitives such as > > kmalloc or spinlocks, and that I wrote the code specifically for the > > Linux kernel, does that make it into a derivative work? > > > > What if I do a trivial replace of the kmalloc calls with malloc and > > the spinlock calls with pthread locks instead, has my code been > > forever tainted by being written for Linux so that I can't do that > > anymore? What if I go the other way and write my code using the > > posix functions to begin with and do the equally trivial replace of > > malloc with kmalloc? > > As the copyright owner, you're free to distribute the original parts > as you wish as long as it doesn't contain anything that is derived > work. Ok good. > So, when you remove those kmalloc/spin_lock calls, you're > _obviously not_ tainted. But that doesn't mean you're free to > distribute it when it _does_ contain derived work. So it magically becomes a derived work if I do a: #define malloc(n) kmalloc(n, 0) #define pthread_mutex_lock(l) spin_lock(l) at the beginning of the file? My guess is that it is much to trivial to be considered a creative expression and thus would not be covered by copyright. Meaning it would not be a derivative work. > Besides, a device > driver can't even be compared to something as trivial as b-tree > implementation that uses kmalloc/spin_lock in terms of "is it derived > work or not." A device driver isn't that hard either. I can write a device driver with a hand tied behind my back, to write a good balancing tree, I'd have to spend a lot more time reading up on algorithms. So "trivial" is a matter of background. And once again, I don't believe API copyrights are valid, because in that case Wine would have been sued out of the water a long time ago. > Thanks for the straw man, though! *sigh* Now you're just being insulting. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Thu, 7 Feb 2008 18:49:39 +0100 Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote: > > It requires software that is *distributed* as part of a GPL > > work to itself be GPL. At time of distribution, a kernel module is > > neither using nor linked to the kernel. > > Oh, come on! You cannot turn a derived work into an original work just > by distributing them seperately. No, but the other way doesn't work either. Lets say that I write a piece of code, a B-tree algorithm. If I take that piece of code and put it in the Linux kernel and distribute it as a statically linked binary kernel, then quite obviously the whole is a derived work of the original Linux kernel and my b-tree code. If I refuse to give the source code to my b-tree code [1] I have obviously violated the GPL. That is very clear and I don't think anyone disputes that. What is more disputed is if my b-tree code is a derivative work of the kernel or not. In my opinion it is not, that b-tree code is my original work and I can ship it as a part of a proprietary product if I want to. If I distribute it as a .o file and somebody links it into the kernel, that is the end users decision, and the GPL explicitly says "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted [...]". But lets say that the b-tree code uses Linux-only primitives such as kmalloc or spinlocks, and that I wrote the code specifically for the Linux kernel, does that make it into a derivative work? kmalloc is only a function call, so I'd say that is too trivial to be copyrightable, APIs or just directories mapping names to numbers are not copyrightable. The spinlocks are a bit more troublesome since they are implemented as macros or inline functions so they do pull in some code from the header files. On the other hand, since they in a way form an API, and are the only way of interoperating with the kernel, they might not be copyrightable either. Then there's the question of fair use which might also make it possible to legally use those functions anyway, even if they are copyrightable. What if I do a trivial replace of the kmalloc calls with malloc and the spinlock calls with pthread locks instead, has my code been forever tainted by being written for Linux so that I can't do that anymore? What if I go the other way and write my code using the posix functions to begin with and do the equally trivial replace of malloc with kmalloc? So static linking vs dynamic linking really isn't the question. But linking something statically and distributing the resulting binary without providing source, that is a very blatant violation of the GPL, so that is fairly easy to bring to court. As far as I know, the question if using the kernel header files creates a derivative work or not has not been decided in court though, and until it has it is a bit of a gray zone. And even if it is decided in a court in Germany for example, that ruling might not apply in the states or in Australia. The Berne convention is supposed to harmonise the copyright laws all over the world, but there are still differences between countries. Every time Harald Welte sues a company and that company settles by paying up, it strengthens the position that the GPL is valid, but since those settlements are made outside of court, no outsider can tell why they settled. Was it because the company had blatantly violated the GPL by refusing to give away source (a lot of WLAN routers made by Chinese companies seemed to fall into that category), was it because they were using GPLed source in their drivers (a lot of binary modem drivers was modified versions of the serial driver straight from the Linux kernel, an obvious violation), or was it because the court hinted that they would actually consider an original device driver written for Linux as a derivative work? Or was it just because the companies felt that the fight wasn't worth the time and money, and it's easier to settle than to spend a lot of money on a fight, especially since there's always a small risk that you can get hurt in a fight? Patent trolls use the same tactics, they sue small companies and offer them settlements which are less risky than fighting it out in court, so most small companies settle. The trolls then use those settlements as "proof" that their claims are valid, and with the settlement money they take on bigger victims. Now, I do consider Welte's suits a wee bit [2] more valid than patent trolls, and I'm happy he has the energy to do that. But using his victories, which usually seem to be regarding very blatant GPL violations, as some kind of proof in the derivative-work-or-not debate, isn't really valid. /Christer (rambling again) [1] Or if I give the source code to the recipient and say "here's the source code, but you can't give it to someone else". [2] That is an understatement, ok? -- To unsubscribe f
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sat, 09 Feb 2008 05:10:04 +1030 David Newall <[EMAIL PROTECTED]> wrote: > Now, Alexander Terekhov has forwarded some links to me, relating to > the question of whether or not a Linux kernel module can be original. > Bear in mind that these links relate to U.S. Copyright Law. Mercy, no, with friends like Alexander you don't need any enemies... He's been fighting windmills for ages. I wouldn't trust his legal opinion at all. He might have some some points, sometimes, but it gets totally lost in all the noise that he produces. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Wed, 06 Feb 2008 21:55:45 +0100 Marcel Holtmann <[EMAIL PROTECTED]> wrote: > > So how does that invalidate my point? Intel did jump through a lot > > of hoops to avoid giving away the code that controls their radio. > > When the regulatory daemon stuff got too much complaints, they > > finally redid their firmware to avoid the daemon. But they still > > have not exposed the details on how to control their radio. > > find an Intel engineer that worked on it. There is a bigger story > behind it and I am not telling it. > > And btw. it is perfectly fine that Intel is not giving full access to > their radios. Why should they? I think it is perfectly within their rights to do so. I think it's kind of silly to try to hide it, if someone wants to boost the maximum transmit power, they're going to hack the firmware anyway. But if it makes Intel happy, well... :-) > > Yes, that is a nice solution. Provided that you have any firmware > > at all. But price is everything, chips become dumber and dumber > > and more control functions are pushed to the host. If you want to > > sell a device in Korea, price is everything; if you can shave off > > 30 cents by putting the firmware in ROM, or by using 1.5 mbits of > > flash instead of 2 mbits, that means an increase in market share or > > profit margins. > > I heard this all before and I don't buy it anymore. At some point the > companies in Asia will understand that the whole picture looks > different and that not always cheap, cheap, cheap is best for their > margins. I've been hoping that they will understand that too. So far it has been a futile hope. It is soo fun to write a design spec saying "Whatever you do, do not use this chip, it sucks. Yes, I know it is 50 cents cheaper than the competition, but it is not worth it." just too see exactly that chip being put into the product. > And btw. the fully supported Linux hardware is in a lot of cases not > more expensive than the other ones. Mmm. I've actually put consulting on the shelf for a while and have become employed by CSR instead. They have a really nice, and as far as I've understood, fairly good and price competitive WIFI chip for low power systems such as mobile phones or PDAs. I've gotten a preliminary go ahead from the bosses to provide documentation under an NDA to Linux developers that would like to write GPL drivers for it. I just haven't had time to do anything more about it yet. And since I'm fairly new to CSR and are located at a remote office, it takes time to find the right people to talk to. > > > Remember that nobody inside the community ever asked for any kind > > > of IP or trade secrets. We only want specifications so we can > > > write the drivers under an appropriate open source license. If the > > > specification describes an API exposed via firmware then that is > > > perfectly fine. > > > > I definitely agree. I think it's stupid of companies to hide away > > their documentation out of fear of, well, something. I find it > > extremely frustrating when I bought a device touted as "the first > > open Linux mobile", just to find out that it used a binary-only > > kernel module for the M-Systems DiskOnChip. A quite nice phone, > > but due to that one module, it was completely impossible to use > > anything but the ancient 2.4 kernel it came with. > > You got one of the Greenphones ;) How could you guess? :-) Actually, I got three of them, and all of them lie unused in a box at work. And the OpenMoko sucks. Or actually, it doesn't suck at all, I'm thinking of buying one just for fun, it's just that I like buttons on a phone, and really don't want a touch screen. So I like the OpenMoko project in every way, it's just not the right phone for me. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Tue, 5 Feb 2008 13:46:08 +0200 "Pekka Enberg" <[EMAIL PROTECTED]> wrote: > Hi David, > > Marcel Holtmann writes: > > > You driver was meant to be running as Linux kernel module and > > > thus it is derivative work. > > On Feb 5, 2008 1:39 PM, David Newall <[EMAIL PROTECTED]> wrote: > > It is precisely the fact that it is a loadable module, and does not > > form part of the kernel, that removes the requirement to distribute > > it under GPL. > > What makes you qualified to make that statement (without giving any > evidence)? Are you're an expert on international copyright law? Are you? You've made some very definite statements about copyright law. Things that I've been told are definitely in a gray area and not at all as clear cut as you and the FSF likes to say. FSF has a very clear agenda, and taking what they say as the gospel is a big mistake. If I link a binary .o file into a static kernel image, does that make it a derivative work of the kernel? It most definitely violates the GPL in that the total is a derivative work, but does it really make the .o file a derivative work? What if I let the user do the linking at runtime? But as Alan Cox wrote, how the linking is done doesn't decide if it is a derivative work or not, copyright law does. So what does make it a derivative work then? If I use an in kernel API, but from a piece of code which is external to the kernel, is that really a derived work? If you say it is, do you realise that you are advocating something which is very close to an API copyright, something which I think most open source people are very adverse to. If API copyrights were valid, Wine, or editline, or lesstiff would be in a lot of trouble. Of course, the Linux headers don't only define an API, they also contain a lot of inline code. But if I don't care about an extra jump, I could write a glue layer between the Linux kernel and some proprietary code that wraps all inline functions. In that case, is a module written against that glue layer a derivative work of the kernel? If I write a glue layer that allows me to run the same driver in userspace via libusb and directly in the kernel, and give the user a choice to link my binary .o file either the userspace or kernel space glue, does that make my code a derivative work of the kernel? Most probably not, it is independent of the kernel in that case. So where is the line in the sand that makes it clearly a derivative work? It's up to the courts to decide, and until there is a clear and final court ruling it is a gray area. Lawyers can guess at what the outcome might be, and some companies are apparently willing to take the risk that it isn't as clear cut as you think. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Wed, 6 Feb 2008 12:28:10 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote: > > On Tue, 5 Feb 2008 12:34:18 -0800 > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > In the end, it's up to the copyright holders to enforce the > > > license. And as I have stated in the past, a number of them have > > > made public statements as to what they think about this issue. > > > And it corresponds exactly with what Marcel has stated above. > > > > > > So if you wish to violate the copyright of others, you take the > > > risk that you might be caught and punished, something that you > > > and your legal council needs to take into account. > > > > So when do you sue Nvidia, ATI, Atheros, Broadcom[1], > > M-Systems/Sandisk[2] or Nokia? All those companies distribute binary > > drivers for Linux without providing source code? > > How do you know that such legal action isn't already happening? I don't. But AFAIK no such lawsuits have been made public so far. ATI/AMD are moving in the right direction already, looking at open sourcing their drivers. (How is that going by the way, I haven't had time to keep up lately). And that I guss might be thanks to the competition from Intel on the graphics side. Or is it due to legal pressure out of the public eye? Or has ATI just realised that the Linux market is big enough that going open source might gain them enough market share to be worth is? Anyway, I'm definitely going to vote with my wallet the next time I buy a laptop. My last laptop had an Intel graphics chip, because of the open source graphics drivers. I chose to buy a slower Intel chip instead of a faster Radeon model. And if something comes out of ATI before I buy a new one, I'll have to graphics chip manufacturers to choose from. But would ATI really have been interested in open sourcing their graphics drives now if they had been sued out of the water a couple of years ago when they did their first binary drivers for Linux? I don't know. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Mon, 04 Feb 2008 22:38:11 +0100 Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Christer, > > while the HAL case of Atheros might be still true despite the fact > that an OpenHAL has been around for a long time now. The Intel > argument is out of the picture since quite some time. The regulatory > daemon was an interim solution and has been replaced by a proper > firmware solution. So please get your examples up-to-date. So how does that invalidate my point? Intel did jump through a lot of hoops to avoid giving away the code that controls their radio. When the regulatory daemon stuff got too much complaints, they finally redid their firmware to avoid the daemon. But they still have not exposed the details on how to control their radio. > You might wanna now point to hiding something in firmware, but the > hardware, firmware, driver separation (with being hardware and > firmware closed source) is an accepted solution. It is a clean > separation. Interface wise and license wise. Yes, that is a nice solution. Provided that you have any firmware at all. But price is everything, chips become dumber and dumber and more control functions are pushed to the host. If you want to sell a device in Korea, price is everything; if you can shave off 30 cents by putting the firmware in ROM, or by using 1.5 mbits of flash instead of 2 mbits, that means an increase in market share or profit margins. > Remember that nobody inside the community ever asked for any kind of > IP or trade secrets. We only want specifications so we can write the > drivers under an appropriate open source license. If the > specification describes an API exposed via firmware then that is > perfectly fine. I definitely agree. I think it's stupid of companies to hide away their documentation out of fear of, well, something. I find it extremely frustrating when I bought a device touted as "the first open Linux mobile", just to find out that it used a binary-only kernel module for the M-Systems DiskOnChip. A quite nice phone, but due to that one module, it was completely impossible to use anything but the ancient 2.4 kernel it came with. I also think that my customers, that decided to keep their kernel modules binary only, made a big mistake and have told them so. But I still think it's better for the Linux community to be a bit soft on such companies for a while. It's better to let them get away with it for a while, and slowly try to convince them about the error of their ways, rather than see them go with Windows CE or a BSD. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Tue, 5 Feb 2008 12:34:18 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > In the end, it's up to the copyright holders to enforce the license. > And as I have stated in the past, a number of them have made public > statements as to what they think about this issue. And it corresponds > exactly with what Marcel has stated above. > > So if you wish to violate the copyright of others, you take the risk > that you might be caught and punished, something that you and your > legal council needs to take into account. So when do you sue Nvidia, ATI, Atheros, Broadcom[1], M-Systems/Sandisk[2] or Nokia? All those companies distribute binary drivers for Linux without providing source code? /Christer [1] WIFI chips and drivers used by Cisco, Asus and a lot of other manufacturers. [2] DiskOnChip devices used in lots of embedded systems, among others the Troll Tech Greenphone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Diego Zuccato wrote: In the cited example it's illegal to go outside certain parameters SOMEWHERE (if it was illegal everywhere, the the hardware shouldn't allow it and the sw could do nothing... not considering hw mods). Another example is WiFi: USA, Europe and Japan allows a different number of channels. But every AP I have had simply asks which country the user is in, then allows only a limited choice for the channel to use. If I'm in Europe but tell my AP that I'm in Japan, it lets me choose channel 13 (Europe allows up to ch 11). If the "cops" find it out, they prosecute ME, not my AP! It's not a TECHNICAL limit, it's a LEGAL one. So there's no point in keeping a driver closed *just* because else someone could hack it to make it work outside the allowed parameters: even a closed driver is hackable (just reverse engineer it...). Think about this scenario: a closed source driver contains: if(power<100) setpower(power); else setpower(100); to limit tx power and make it legal. Then the user finds this 100 and replaces it with 255 (inside the binary-only module), actually allowing for more than twice (if power is in mW) the legally permitted power. Is it legal? I don't think so (and I doubt you can find any lawyer that does). But it's not THE DRIVER that's doing something illegal. It's THE USER. It would be equally illegal if the driver was open source. Simpler to do, but equally illegal. It isn't that easy. The "Tamper-Proof Torx" screws on a vacuum cleaner or a toaster won't stop anybody from opening up the thing, I mean every little hardware store stocks those Torx bits. But by using a slightly odd screw, the company can say "look, we'we done all we can to stop them, but the user bypassed our security device, and it's not our fault". Apparently Intel and Atheros are trying to protect themselves in a similar way, they Open Source everything except for the regulatory daemon (Intel) or HAL object file (Atheros). Why? Because they belive that if they give away the sources to those parts they do the software equivalent of putting a normal Phillips screw in a home appliance. (Personally I think what they are doing is ridiculous, but apparently those companies' lawyers dont' agree). It's of course possible to argue that normal users don't compile their own drivers, they use a driver from their distribution maker, and compiling a hacked driver which allows them to override the limits is just as hard as it is for a Windows user to replace the driver binary with a hacked binary which overrides the limits, so hiding the source really doesn't help. Another example: how do you detect, from a driver, if the user actually got a license/permission from the government (somewhere it's needed, or you need to pay an annual fee) to use the device? You can't. Does this missing check make the device illegal? Nope. Just its USE. Welcome to the modern world, companies spend so much money on protecting themselves against potential lawsuit that it is silly. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
Pekka Enberg wrote: Why are we discussing this again? The Linux kernel is distributed under the GPLv2 and even though there are some legal gray areas regarding derived work (think nvidia and ati binary blobs here), the license is not friendly towards proprietary drivers at all. Why? Because it is a gray area. I still have my reservations about the GPL being as viral as FSF says it is. Greg KH's lawyer says one thing, some legal departments I've talked to say something else (or they express it in laywerese, but it boils down to "you can probably get away with it") and apparently both nvidia's and ati's legal departmens think so too. And because I belive it's very important not to scare away Linux users unneccesarily. Yes, the kernel does not, and should not be friendly towards proprietary drivers, but there is a difference between not being friendly and being actively hostile. Furthermore, many of the _kernel developers_ do not support proprietary drivers, so why do you insist on using Linux for that purpose? You did read the rest of the mail you commented I hope? Seriously, you really really want to look at the BSDs or proprietary operating systems because they support your needs much better. So you'd rather have the Nokia 770 use BSD because Nokia couldn't find a low power WLAN chip with a GPLed driver? You'd rather see Nokia spend man-years on improving the support for the TI OMAP CPU's somewhere else than Linux? Yes, it sucks that the on WLAN Nokia 770 doesn't have an open driver, but I'm very happy that Nokia has spent all that effort on getting Linux to run well on the 770 and has given 99% of that work back to the Linux community. (Actually, I think there is a GPLed driver for the WLAN now, but that driver would most probably not have been written unless the Nokia 770 hardware had been out there so that frustrated Linux hackers decided to do something about it). And why is it ok for nvidia and ati to have proprietary drivers? Is it ok just because people are afraid to alienate them if they push too hard? Having no 3D graphics at all on Linux is a nightmare scenario for the distro makers, so I guess that's why people try not to rock the boat too much. So why don't you send in a patch that makes all EXPORTS into EXPORT_GPL? That would be the only honest course of action according to you, wouldn't it? /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sat, 2 Feb 2008 11:19:30 -0800 Greg KH <[EMAIL PROTECTED]> wrote: >I do know that the current usbfs interface is a major pain, hence the >work to create usbfs2. I know those developers could use the help in >getting that cleaned up and into the kernel tree. >Also see the rapid development these days in wrappers around usbfs. >There is competing projects right now with OpenUSB and the >revitalization of the old libusb project. I know those developers are >looking for examples where their new frameworks do not meet the needs of >developers for stuff exactly like you describe (lots of threads, async >callbacks, high throughput, cross-platform portability, etc.) Yes, I did spend quite a lot of time the last time looking for usable USB APIs, and I did not manage to find any. Unfortunately, my time is also limited, and I'd much prefer to work on getting support for Samsungs ARM CPUs into Linux. When I'm doing paid work for a customer and they want to a proprietary driver, I'm not going to spend a lot of my free time on working around that decision. I explain to them that binary drivers are definitely in a grey area and they might get in trouble about it, but at the end it is their decision. > > I've written multiple of them during my life as a consultant. The > > nature of closed source drivers is that they quite often are written > > for custom hardware that isn't used by that many people, so you have > > probably not seen them, but they are definitely out there in the > > wild. > > It comes down to the simple fact, if you wish to use Linux, abide by > the license it comes under. To do otherwise is both disenginous and > illegal[1]. > > If a company wants to keep a driver closed, then use another operating > system, it's not like there isn't other options out there. I hear the > BSDs and Microsoft are quite comfortable with things like that. :) So in other words you want to crack down on GPL violations, and you're going to ignore anyone who does have a proprietary driver as "not relevant" or "it can be done with usbfs" (maybe). So why even ask on the mailing list? Just do it. Saying "use BSD" instead isn't a good answer for me since I don't know BSD well enough. And personally, I want to see Linux everywhere; I think it's a lot better to have Linux + a proprietary driver in an embedded system than BSD or Windows CE. It means that the customers get used to Linux, and if I can get them to at least contribute back a bit (any improvements to the core kernel for example), to me that is a lot better than giving a lot more money to BillG. Later, when I can show them how much easier everything gets if they use open drivers (I'd never have managed to get my latest Samsung platform up and running as quickly as I did without the patches I got from Sandeep Patil, and by posting my patches to his patches I got some feedback that helped me fix a bunch of bugs). But it usually takes some time to convince a company that the things they get back is more valuable than keeping things proprietary. So I think Linux as a whole gains a lot more by being a bit lenient about proprietary drivers. That is why I'm opposed this change of yours. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Fri, 25 Jan 2008 10:02:32 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > FYI, this is a patch that will be sent out in the next round to Linus > for inclusion in 2.6.25. > > If anyone has any objections about it, please let me know. Yes, I have objections and I've told you before. > Over two years ago, the Linux USB developers stated that they believed > there was no way to create a USB kernel driver that was not under the > GPL. This patch moves the USB apis to enforce that decision. > > There are no known closed source USB drivers in the wild, so this > patch should cause no problems. This is a bit disingenuous. Of course there are closed source USB drivers out there. I've written multiple of them during my life as a consultant. The nature of closed source drivers is that they quite often are written for custom hardware that isn't used by that many people, so you have probably not seen them, but they are definitely out there in the wild. For some of these drivers, being in kernel space is very important since they transfer large amounts of data with very tight latency requirements. It may, in theory, be possible to do the same thing in userspace with multiple cooperative threads and libusb, but it would be much more complex and much more error prone (it's hard to do control loops where you need about 40 us turnaround time). Yes, I'd much prefer if all companies would just publish their sources as GPL, but some companies, rightly or nor, believe that they expose too much information about their custom hardware if they do. And I do feel that such a rabid GPL-stance is going to alienate those companies. Most of those companies also select one kernel for their custom hardware and use that kernel for a long time, so for them this feature removal will come as a bit of a surprise. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The ext3 way of journalling
On Mon, 14 Jan 2008 10:57:09 +0100 Bernd Petrovitsch <[EMAIL PROTECTED]> wrote: > On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote: > > On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote: > > > Yes, that is a usual bug/problem in common distributions[0] as > > > there is no real guarantee that your clock is not far off. > > > > It isn't, right after boot. But while the system is on, it sometimes > > starts advancing very fast, 15min a day or so. To my knowledge, the > > time the CMOS clock is not used then, but rather the kernel tracks > > the > > > time based on scheduler interrupts, with ntpd occasionally > > correcting. However, ntpd refuses to correct when the time has > > drifted too much, causing even further drift. > > That shouldn't happen. > > Nope, as explained above. ntpdate at boot wouldn't help much, > > because the time is (approximately) correct after boot. It only > > drifts after it. > > Aha. That's also strange. `ntpd` is able to (and always does AFAIK) > modify the speed of the clock (to keep it synchronized) so that the > error is usually much smaller than 1 second - also if you are behind > high-jitter links and/or an a high stratum. > That leads to the question why the clock starts to run like crazy at > some time so that `ntpd` can't cope with it. > Playing with `ntpd` parameters (e.g. increasing ) doesn't help I > assume. NTP can't correct too large errors. I had some similar problems (one of many problems) with my HP Proliant desktop. Something totally messed up the timekeeping, so the system would drift up to an hour or so per day. I don't know what was wrong, I tried a lot of combinations of timer options, but couldn't find any that fixed it. A kernel upgrade a couple of weeks later fixed those problems and the system time has been stable since then. So upgrading to a recent kernel is probably a good idea. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Wed, 09 Jan 2008 10:18:11 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Zachary Amsden wrote: > > > > I'm speaking specifically in terms of 64-bit platforms here. > > Shouldn't we unconditionally drop outb_p doing extra port I/O on > > 64-bit architectures? Especially considering they don't even have > > an ISA bus where the decode timing could even matter? > > > > Why should the bitsize of the CPU matter for this? It seems one of > the less meaningful keys for this. Well, anything that runs x86_64 should be a fairly modern system. > Second, as I have mentioned, I don't believe this is really the case, > especially not for the PIT, which is still present -- the PIT > *semantics* has explicit timing constraints. > > Third, you still have ISA devices, they're just called LPC or PC104 > devices these days. Or PCMCIA. I'm still a happy user of a Zyxel ZyAIR 100B, it's one of the most stable cards Wifi I've got running under Linux. :-) /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 08 Jan 2008 18:52:42 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote: > On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote: > > Alan Cox wrote: > > > The natsemi docs here say otherwise. I trust them not you. > > > > > As well you should. I am honestly curious (for my own satisfaction) > > as to what the natsemi docs say the delay code should do (can't > > imagine they say "use io port 80 because it is unused"). I don't > > have any > > What is the outcome of this thread? Are we going to use timing based > port delays, or can we finally drop these things entirely on 64-bit > architectures? > > I a have a doubly vested interest in this, both as the owner of an > affected HP dv9210us laptop and as a maintainer of paravirt code - and > would like 64-bit Linux code to stop using I/O to port 0x80 in both > cases (as I suspect would every other person involved with > virtualization). > > I've tried to follow this thread, but with all the jabs, 1-ups, and > obscure legacy hardware pageantry going on, it isn't clear what we're > really doing. I belive Alan Cox is doing a review of some drivers, to see if they actually need the I/O port delay. A lot of drivers probably use outb_p just because it was copy-pasted from some other driver and it can be removed. Alan's review has also brought to light a lack of locking in some drivers, so I think Alan has been adding proper locking to some of the watchdog drivers. Most old ISA only device drivers can keep using OUT 80h. They are not used on modern machines and it's better to keep them unchanged to avoid unneccesary incompatibilities. As far as I know, the 8253 PIT timer code needs outb_p on some older platform, and this is one of the most troublesome since the same PIT controller (or a register compatible one) has been used since the original IBM PC, and it is frequently executed code. Ingo Molnar has done an alternate implementation of the PIT clock source which uses udelay instead of OUT 80h to delay accesses to the ports. The kernel could make a choice of which variant to use based on the DMI year, if compiling for x86_64, or something similar. Maybe have a command line option too. The keyboard controller on some platform needs the delay, and the same driver is used on both ancient and modern systems, I think it can be changed to udelay since it's not so time critical code. The 8259 interrupt controller on some platform needs the delay, I think it can be changed to udelay since it's only some setup code that uses outb_p. I guess there are time critical accesses to the interrupt controller from assembly code somewhere to acknowledge interrupts, and that code needs a review. The floppy controller code uses outb_p. Even though there might be floppy controllers on modern systems, I'd rather leave the floppy code alone since it's supposed to be very fragile. If you still use floppies you deserve what you get. Some specific drivers, such as drivers for 8390 or 8390 clone based network cards are also a bit troublesome, they do need outb_p (and the delay for the original 8390 chip is specified in bus cycles), and there can be a big performance loss if pessimistic udelays are used for the delay. There are still a bunch of PCMCIA cards based on that chip which means that those cards can be used with modern machines. There are also PCI and memory mapped variants of the 8390, some of them new designs which are only register compatible, some other designs are using a real 8390 with a FPGA used as glue logic. I think Alan suggested compiling two versions of that driver, one with OUT 80h, and one with udelay. Old machines can choose the old driver, and new machines can use the new one. Other drivers can probably do the same thing, or if not time critical, always use a pessimistic udelay. As for the implementation, I like the suggestion to split outb_b into two calls, one to outb and one to isa_slow_down_io. It makes it very obvious that it is really two function calls, and that it needs locking. For those uses that are not ISA port accesses, isa_slow_down_io should be changed to an appropriate udelay instead. The goal is anyway that a modern machine should not do OUT 80h, and old machines keep doing it since it has been working well for some 15-odd years, both in DOS device drivers and on Linux. Using an alternate port may be a workaround, but it's probaby not a good idea since alternate ports have received less testing and there's bound to be some platform out there that has problems with any alternate port we might choose. Allowing an alternate port will also add code bloat (OUT 80h, AL becomes MOV DX, alternate_port; OUT DX, AL) for a dubious gain. Did I miss anyting? /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 08 Jan 2008 15:28:03 -0500 "David P. Reed" <[EMAIL PROTECTED]> wrote: > Register compatible. Not the same chips or even the same masks or > timing requirements. No, but somehow people keep making similar mistakes. The DEC HiNote needed outb_p to function correctly? That was definitely a much more modern design than the original PC and most probably did not use any discrete Intel chips, but the same timing problems were there. I belive that problem had to do with the keyboard controller though. > > The discrete Intel > > chips or clones got aggregated into Super I/O chips, and the Super > > I/O chips were put on a LPC bus (an ISA bus with another name) or > > integrated into the southbrige. > Don't try to teach your grandmother to suck eggs: I've been > programming PC compatibles since probably before you were able to do > long division - including writing code on the first prototype IBM > PCs, the first pre-manufacturing PC-ATs, and zillions of clones. > (and I was also involved in designing hardware including the > so-called "Lotus Intel" expanded memory cards and the original PC > cards) Argument by personal authority. Thats good. I guess that's why you don't seem to understand the difference between reading the serial port status register and not being allowed to access a register at all due to such this as the 4 cycle delay you quoted yourself from the 8390 data sheet, and similar issues with the I8253 that I quoted from its data sheet a few posts ago. > The 8259 PIC is an *interrupt controller*. It was NEVER > present in a Super I/O chip, or an LPC chip. Its functionality was > absorbed into the chipsets that control interrupt mapping, like the > PIIX and the nForce. Yup, sorry about that, it got integrated into some other chip instead. I was thinking of another timer, the RTC which is usually a part of the Super I/O. And which is yet another troublesome area since apparently a lot of chipsets have problems with it. But the sequence is the same, discrete chips get aggregated into larger chips. Sometimes the sometimes old macrocells are reused, sometimes they are redesigned from scratch (and new bugs are introduced). > > And the "if it ain't broken, don't fix > > it" mantra probably means that some modern chipsets are still using > > exactly the same internal design as the 25 year old chips and will > > still be subject to some of those ancient limitations. > > > Oh, come on. Give the VLSI designers some credit for brains. The > CAD tools used to design the 8259 and 8253 were so primitive you > couldn't even get a chip manufactured with designs from that era > today. When people design chips today they do it with simulators > that can't even work, and testers that run from test suites that were > not available at the time. And they still keep making the same mistakes... Registers that require wait states before being read again, register that assume that there are going to be some spare cycles between each access so that some internal logic has time to update, registers that would have needed a one byte FIFO to avoid DMA overruns (I'd almost forgotten about that specific bug on SPI controller of the Samsung 2410, but it bit me last week and I only managed to chase it down properly yesterday), and so on. I'm quite impressed with what some VLSI designers manage to do. I just saw a company roll out a completely new ARM9 design with lots of fun stuff and as far as I know they only made one single mistake on that chip. On the other hand, on other designs you can see how the same old macrocell has been reused long past the "best before" date, because some bugs crop up over and over again. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-kernel] Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 08 Jan 2008 13:44:54 -0500 "David P. Reed" <[EMAIL PROTECTED]> wrote: > Ondrej Zary wrote: > > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote: > > > >> Windows these days does delays with timing loops or the > >> scheduler. It doesn't use a "port". Also, Windows XP only > >> supports machines that tend not to have timing problems that use > >> delays. Instead, if a device takes a while to respond, it has a > >> "busy bit" in some port or memory slot that can be tested. > >> > There is no need to use io writes to supposedly/theoretically "unused > ports" to make drivers work on any bus. > ISA included! You can, for example, wait for an ISA bus serial > adapter to put out its next character by looping reading the port > that has the output buffer full flag in a tight loop, with no delay > code at all. And if you need to time things, just call a timing loop > subroutine that you calibrate at boot time. Now you're totally confusing things. You're talking about looking at bits in a register to see if a transmit register is empty. That's easy. The delays needed for the Intel M8259 and M8253 say that you're not even allowed to access the registers _at_ _all_ for some time after a register access. If you do a write to a register immediately followed by any access, including a read of the status register, you can corrupt the state of the chip. And the Intel chips are not the only ones with that kind of brain damage. But what makes the 8259 and 8253 a big problem is that every modern PC has a descendant of those chips in them. The discrete Intel chips or clones got aggregated into Super I/O chips, and the Super I/O chips were put on a LPC bus (an ISA bus with another name) or integrated into the southbrige. And the "if it ain't broken, don't fix it" mantra probably means that some modern chipsets are still using exactly the same internal design as the 25 year old chips and will still be subject to some of those ancient limitations. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Mon, 07 Jan 2008 20:38:09 +0100 Bodo Eggert <[EMAIL PROTECTED]> wrote: > Christer Weinigel <[EMAIL PROTECTED]> wrote: > > > How do you find out the speed of the ISA bus? AFAIK there is no > > standardized way to do that. On the Geode SC2200 the ISA bus speed > > is usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or > > 30/4=7.5MHz, but with no external ISA devices it's possible to > > overclock the ISA bus to /3 to run it at 11MHz or so. But without > > poking at some CPU and southbridge specific registers to find out > > the PCI bus speed and the ISA bus divisor you can't really tell. > > If you overclock, you are on your own. IIRC I've used 13,3 MHz for > some time and used a lower PIO mode to compensate. That would not be overclocking, rather that the hardware designer would have determined that on that specific hardware design, all peripherals are able to run at 12MHz. Also note that on some other system the hardware designer might have decided to have a slower ISA clock, to save power, fulfil some EMI requirement or whatever. > > So if you do udelay based on a 6MHz clock (I think you can safely > > assume that any 386 based system runs the ISA bus at least that > > fast) you'll waste at least 30% and maybe even 100% more time for > > the delay after every _p call. > > Defaulting to 8 MHz and offering an option to set another clock speed > (like idebus=) should be OK. Sounds like a big regression to have to start using a command line option, when the current state of affairs is "it just works". /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] teach checkpatch.pl about list_for_each
On Thu, 03 Jan 2008 17:17:29 +0200
Benny Halevy <[EMAIL PROTECTED]> wrote:
> On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo
> > Agreed, CodingStyle is not about mindless consistency such as "for
> > (" is the right thing, so "list_for_each (" is consistent with it,
> > it is about codifying practice contributors got used to over the
> > years.
> >
>
> Why mindless?
> Coding style is also about giving the coding language logic a
> graphical representation. Following a convention that flow control
> keywords such as "if", "for", or "while" are distinguished from
> function calls by use of a space after the keyword really helps the
> code readability regardless of how people used to code it in the
> past... The for_each_* macros are clearly not function calls but
> rather translate to for () flow control constructs hence they should
> follow the same convention. FWIW, I think that changing the existing
> convention is worth it in this case.
Definite agreement here, since _for_each is used for flow control, that
space should be there.
And some people seem to take checkpatch.pl as the gospel, and won't
apply code with checkpatch warnings.
/Christer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] teach checkpatch.pl about list_for_each
On Thu, 03 Jan 2008 13:34:45 +0100 Tomas Carnecky <[EMAIL PROTECTED]> wrote: > Christer Weinigel wrote: > > By the way, what is the consensus on lines over 80 characters? > > checkpatch complains about the following: > > > > WARNING: line over 80 characters > > #762: FILE: drivers/spi/spi_s3c24xx_dma.c:720: > > + printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav > > Technologies AB\n"); > > > > I can of course break this into: > > > > printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav " > >"Technologies AB\n"); > > > > but in my opinion that becomes more even unreadable. Would it be > > possible to add a special case so that checkpatch ignores long > > strings that go beyond 80 characters? Do you think it is a good > > idea? > > At the top of the file add a #define and use that in the code? Some > drivers define their version/author etc that way and then just > printk(DRIVER_VERSION DRIVER_AUTHOR); That only solves this specific problem. For debugging printks, which often become quite wide, it would make the code even more unreadable to add lots of defines just to keep things within 80 cols. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Wed, 02 Jan 2008 00:11:54 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > Well, on the PIIX it is and I guess on anything where it's _not_ > fully internal an 0xf0 write wouldn't have any effect on IRQ13... > > When you earlier mentioned this it seemed 0xed switched on DMI would > be good enough, but well. > > Alan, do you have an opinion on the port 0xf0 write? It should > probably still be combined with a replacement/deletion for new > machines due to the bus-locking "bad for real-time" thing you > mentioned earlier but in the short run it could be a fairly > low-impact replacement on anything except a 386+387 Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan SC400 processor. It is an AMD 486 based system on a chip and since AMD just knew that it would never have a math coprocessor, they reused the 0xf0-0xf2 range for the PCMCIA controller. I guess the AMD Elan SC500 will have similar problems. I seem to recall that back when I was working with the Elan SC400 (sometime around 1998?) there were discussions about finding an alternate delay port because outb to 0x80 messed up the debug port. I think the Elan stopped those discussions because just about every port on the Elan was reused for some alternate purpose. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 1 Jan 2008 23:12:50 + Alan Cox <[EMAIL PROTECTED]> wrote: > > Besides the above there are only a handful of _p uses outside of > > real ISA device drivers, and those should not be relevant for a > > modern PC unless somebody wants to use an 8390 based PCMCIA card, > > but we could tell them "don't do that then". > > We need to build 8390.c twice anyway - once for PCI once for ISA with > the _p changes whichever way it gets done. PCMCIA can use whichever > we decide is right. Anyone know if PCMCIA is guaranteed to be 8MHz ? It's not. It's perfectly ok to drive a PCMCIA bus slower than that, IIRC we used a much slower clock speed than that on a StrongARM platform I worked a couple of years ago. The PCMCIA CIS (Card information services) allows the following device speeds: 100, 150, 200 and 250 ns. The memory card spec also allows 600 and 300 ns. The standard I/O card cycle speed is 255 ns. I believe that is "the shortest access time for a read/write cycle", and I can't tell if that is comparable to one ISA clock cycles or if it's comparable to 8 ISA bus cycles. On the other hand, there is no clock line in a PCMCIA connector, so for PCMCIA devices any delays should be absolute times, or based on some clock that is internal to the card. How that fits with the 8390 data sheet talking about bus clocks, I don't know. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 01 Jan 2008 13:21:47 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > Christer Weinigel wrote: > > > > out 80h, al is only two bytes. Any alternative that has been > > suggested in this discussion will use more space. mov dx, > > alt_port; out dx, al will be larger, a function call will > > definitely be a lot larger. People have been making changes to the > > kernel to save a couple of hundred bytes of text size. > > If text size becomes a problem in this case, then we can use an > alternatives-like mechanism to fix up the kernel. However, > realistically this probably should be a function call *combined with* > the out and in; that reduces the impact somewhat. That's a very good point. So for the PIT it should be possible to have two clocksources, one with the _p and one without, that one can switch between with a kernel command line option. So there shouldn't be any slowdown at all due to that. The i8259 init code is not time critical, so should be able to use a "reasonable" delay. Besides the above there are only a handful of _p uses outside of real ISA device drivers, and those should not be relevant for a modern PC unless somebody wants to use an 8390 based PCMCIA card, but we could tell them "don't do that then". But I'd better shut up and let Alan continue on his review of the _p use in the drivers. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 1 Jan 2008 22:01:43 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > out 80h, al is only two bytes. Any alternative that has been > > suggested in this discussion will use more space. mov dx, > > alt_port; out dx, al will be larger, a function call will > > definitely be a lot larger. People have been making changes to the > > kernel to save a couple of hundred bytes of text size. > > i've done dozens of patches that saved much less of text size, so > yes, i very much care about code size. But it has been stated in this > thread that most of the _p() API uses in the kernel today are bogus. > So eventually getting rid of the bogus ones will be a net code size > _reduction_. (But even that is besides the point, we prefer clean and > easier to maintain code.) And once again, the _p in the code that talks to the PIT is very much non-bogus. And it is a critical path that's called a lot. The i8253 PIT and the i8259 interrupt controller are probably the only ones that are relevant on a modern machine, and it seems that even some fairly modern chipsets have limitations on how fast you can drive them. BTW, I just checked the Intel M8253 data sheet (dead tree variant), and it says under A.C Characteristics, READ CYCLE: Recovery Time Between /READ and Any Other Control Signal: 1 us So at least for the original M8253 a udelay(1) might be more appropriate than outb_p, since the delay is not expressed in clock cycles but absolute time. The data sheet for the Intel M8259A says: End of /RD to Next Command: 300 ns End of /WR to Next Command: 370 ns On the other hand, I don't know how all the i8253/i8259 clones or the numerous variants of Super I/O chips behave. It wouldn't surprise me if some Super I/O chip uses the ISA bus clock to latch the values internally so that the delay is dependent on the bus frequency instead. > > I don't know if the difference in code size or the udelay will be > > significantly slower, but I think it might be. > > ok, "I dont know but it might be slower" is a perfectly fine > statement instead of your original "it will be slower". I didn't say that, I said I'm afraid it will be slower. :-) /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 01 Jan 2008 20:59:20 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > On 01-01-08 20:35, Christer Weinigel wrote: > > > On old hardware (or anything with an ISA bus which I'd guess > > includes the Geode SCx200 SoC which is basically a MediaGX > > processor, a southbridge and an ISA bus with a Super I/O chip on > > it) an out to 80h will use exactly one ISA cycle. > > Not to disagree with the point but more like 8 (1 us at 8 MHz). It's > the timeout property. Ah, sorry, you're right of course. > > I'm not sure what Alan meant with his comments about locking, but if > > changing outb_p to use an udelay means that we have to add locking, > > that is also going to affect the code size and speed. > > Explained here: > > http://lkml.org/lkml/2007/12/30/136 > > However, that's not an argument. Missing locking is a bug, and > current outb I/O delay use hiding it doesn't change that. Thanks, I had missed that one. Regarding Alan's comment: >For that matter does anyone actually have video cards old enough for us >to care actually still in use with Linux today ? I'm afraid that some PC104 systems may still use ancient video cards. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 1 Jan 2008 19:45:24 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Alan Cox <[EMAIL PROTECTED]> wrote: > > > > there strong counter-arguments against doing the clean thing and > > > adding an udelay(2) (or udelay(1)) to replace those _p() uses in > > > ISA drivers? > > > > #1 udelay has to be for the worst case bus clock (6MHz) while the > > #device may be at 10Mhz or even 12MHz ISA. So it slows it down stuff > > unneccessarily- and stuff that really really is slow enough as is. > > udelay is supposed to be reliable. If someone runs a new kernel and > has no TSC (which might happen even on modern hardware or with notsc) > _and_ finds that udelay is not calibrated well enough then that's a > kernel bug we want to fix. How do you find out the speed of the ISA bus? AFAIK there is no standardized way to do that. On the Geode SC2200 the ISA bus speed is usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or 30/4=7.5MHz, but with no external ISA devices it's possible to overclock the ISA bus to /3 to run it at 11MHz or so. But without poking at some CPU and southbridge specific registers to find out the PCI bus speed and the ISA bus divisor you can't really tell. So if you do udelay based on a 6MHz clock (I think you can safely assume that any 386 based system runs the ISA bus at least that fast) you'll waste at least 30% and maybe even 100% more time for the delay after every _p call. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 1 Jan 2008 19:46:59 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Christer Weinigel <[EMAIL PROTECTED]> wrote: > > > What I'm afraid is that udelay will be significantly slower, [...] > > why should it be significantly slower? out 80h, al is only two bytes. Any alternative that has been suggested in this discussion will use more space. mov dx, alt_port; out dx, al will be larger, a function call will definitely be a lot larger. People have been making changes to the kernel to save a couple of hundred bytes of text size. On old hardware (or anything with an ISA bus which I'd guess includes the Geode SCx200 SoC which is basically a MediaGX processor, a southbridge and an ISA bus with a Super I/O chip on it) an out to 80h will use exactly one ISA cycle. A call to udelay will need a margin, so it will be slightly slower. And that's assuming that you can find out the speed of the ISA bus, if you can't you'll have to assume the slowest possible bus (6 MHz I guess) which will be a lot slower. I don't know if the difference in code size or the udelay will be significantly slower, but I think it might be. And to take the MediaGX as an example, the TSC is not usable on that CPU, so Linux has to use the PIT timer for gettimeofday. As I wrote in a different post, I believe the PIT on the SCx200 needs outb_p to work reliably. So if outb_p becomes significantly slower that will affect a critical path on a very common embedded CPU. I'm not sure what Alan meant with his comments about locking, but if changing outb_p to use an udelay means that we have to add locking, that is also going to affect the code size and speed. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.
On Tue, 1 Jan 2008 17:43:38 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > if someone runs a fresh new kernel on an ancient device then timings > _will_ change a bit, no matter what we do. Alignments change, the > compiler output will change (old compilers get deprecated so a new > compiler might have to be picked), cache effects change - and this is > inevitable. The important thing is to not eliminate the delays - but > we sure dont have to keep them cycle accurate (we couldnt even if we > wanted to). The only way to get the _exact same_ behavior is to not > change the kernel at all. What I'm afraid is that udelay will be significantly slower, which might hit anything that does a lot of gettimeofday calls (poking at the PIT timer) on embedded 386/486 systems. On the other hand, those systems might not want to upgrade to 2.6 anyway. And why do people keep buying HP hardware? HP seem to be quite Linux-unfriendly on the desktop [1] and on their laptops. Apparently HP doesn't even bother to try Linux on any of their non-server systems. [1] Try running Linux on a HP DC7700 machine, there seems to be a lot of magic stuff in those machines that doesn't work well with Linux. They had some ACPI crap that stopped FC7 from booting without a lot of magic PCI access options and audio still does not work. /Christer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override
On Sun, 30 Dec 2007 21:13:29 + Alan Cox <[EMAIL PROTECTED]> wrote: > > But that does't mean that other ports won't have the same timings. > > Also, it doesn't mean that we really need to have exactly *those* > > timings. > > For ISA bus you want "at least" those timings. That is an easy case > anyway - ISA bus boxes, old processors and generally no TSC so we can > fall back to 0x80 - we know from 15 years experience the problem only > occurs with recent non ISA systems that have borked firmware. > > Lots of ISA hardware does really need the delays and most of it will > be on old processors as well naturally enough. If I recall correctly, the MediaGX/Geode processor does need _p for the PIT accesses, and that CPU family does have a TSC (even though the TSC stops at times so is hard to use). I also seem to remember that the breakage did not happen very often, but running a system without _p overnight usually showed one hiccup where a read from the counter got corrupted. So unless I'm wrong (which I very well could be, it's been a couple of years since I was debugging the PIT code on a misbehaving Geode SC1200 based system) there is at least one fairly modern CPU, which is used in lots of embedded systems, and in active use, which does need the _p. Just a data point... It's not only ancient systems that need _p. /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] teach checkpatch.pl about list_for_each
Hi Andy,
you seem to be the last person messing around with checkpatch.pl so I'm
addressing this to you. :-)
checkpatch complains about the following:
WARNING: no space between function name and open parenthesis '('
#520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
+ list_for_each_entry (transfer, &message->transfers, transfer_list) {
which I think is a bit bogus since it actually is a for statement in
disguise. The following patch adds list_for_each to the list of things
that look like functions that it shouldn't complain about.
By the way, what is the consensus on lines over 80 characters?
checkpatch complains about the following:
WARNING: line over 80 characters
#762: FILE: drivers/spi/spi_s3c24xx_dma.c:720:
+ printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav Technologies
AB\n");
I can of course break this into:
printk(KERN_INFO "S3C24xx SPI DMA driver (c) 2007 Nordnav "
"Technologies AB\n");
but in my opinion that becomes more even unreadable. Would it be
possible to add a special case so that checkpatch ignores long strings
that go beyond 80 characters? Do you think it is a good idea?
/Christer
Index: linux-2.6.23/scripts/checkpatch.pl
===
--- linux-2.6.23.orig/scripts/checkpatch.pl
+++ linux-2.6.23/scripts/checkpatch.pl
@@ -681,7 +681,7 @@ sub process {
# check for spaces between functions and their parentheses.
if ($line =~ /($Ident)\s+\(/ &&
- $1 !~
/^(?:if|for|while|switch|return|volatile|__volatile__|__attribute__|format|__extension__|Copyright)$/
&&
+ $1 !~
/^(?:if|for|while|switch|list_for_each.*|return|volatile|__volatile__|__attribute__|format|__extension__|Copyright)$/
&&
$line !~ /$Type\s+\(/ && $line !~ /^.\#\s*define\b/) {
WARN("no space between function name and open
parenthesis '('\n" . $herecurr);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sys_chroot+sys_fchdir Fix
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> For sure, "a root user can get out of a chroot a million different
> ways." Young Alan said as much at the beginning of this
> conversation, and I have always agreed. I don't hope to secure Linux
> within chroot, simply to fix chroot so that it does what it says it
> does.
> The problem is leaving cwd unchanged. Once you've set cwd within the
> new root, dot-dot is promised to keep you within that root; and so it
> does. But by leaving cwd unchanged, if you do a subsequent chroot,
> that promise is suddenly broken. I think this is a bug. I think
> that behavior was not intended. Not all agree with me, but obviously
> a lot do, otherwise OpenBSD and others wouldn't have addressed this
> exact issue. Here's what they do:
So keep reading the links I gave you:
http://www.unixwiz.net/techtips/chroot-practices.html
The chroot call itself does not change the working directory, so
if the new root is below the current directory, the application
can still have access outside resources.
http://www.bpfh.net/simes/computing/chroot-break.html
chdir("/foo/bar");
chroot("/foo/bar");
Note the use of the chdir() call before the chroot() call. This is
to ensure that the working directory of the process is within the
chroot()ed area before the chroot() call takes place. This is due
to most implementations of chroot() not changing the working
directory of the process to within the directory the process is
now chroot()ed in.
http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/
The chroot() call itself will only change the root file system in
the process' context. A chroot() call must be followed by a
chdir("/") call in order to reset the current working directory.
So the OpenBSD man page seems to be in the minority here. Any portable
code can not assume that CWD changes. And changing the Linux behaviour
now would be a rather big change which might break userspace. And yes,
there are applications that rely on this, I've used it when building
software for cross compiling.
/Christer
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
> > *spends five minutes with Google*
> >
> > From the OpenBSD FAQ (an operating system most know for being
> > really, really focused on security):
> >
> > http://www.openbsd.org/faq/faq10.html
> >
> > Any application which has to assume root privileges to operate
> > is pointless to attempt to chroot(2), as root can generally escape a
> > chroot(2).
> >
>
> For sure, "a root user can get out of a chroot a million different
> ways." Young Alan said as much at the beginning of this
> conversation, and I have always agreed. I don't hope to secure Linux
> within chroot, simply to fix chroot so that it does what it says it
> does.
>
> Look, when chroot was being designed, I think they intended that even
> root should be unable to get out. They went so far as to say that
> dot-dot wouldn't let you out; and it doesn't. It's not dot-dot
> that's the problem. Even fchdir is no problem, because you choose
> which file descriptors to leave open. Fchdir is actually one of the
> answers. ("What if we need a way to escape?")
>
> The problem is leaving cwd unchanged. Once you've set cwd within the
> new root, dot-dot is promised to keep you within that root; and so it
> does. But by leaving cwd unchanged, if you do a subsequent chroot,
> that promise is suddenly broken. I think this is a bug. I think
> that behavior was not intended. Not all agree with me, but obviously
> a lot do, otherwise OpenBSD and others wouldn't have addressed this
> exact issue. Here's what they do:
>
> "If the program is already running with an altered root directory,
> the process's current directory is changed to the same new root
> directory. This prevents the current directory from being further
> up the directory tree than the altered root directory."
> -- OpenBSD man 2 chroot
>
>
> This was no more than an attempt to fix a long-standing bug.
>
> As stated, opinion is divided as to whether this is a bug. I think
> it is, and many people agree, for example some of the BSDs and
> probably others; some people don't. Young Alan, for example, ummm,
> strongly (is a good word) disagrees. I don't see that it calls for
> nastiness or emotion, and although opinion on this august list is
> divided, apparently the nays are in the majority. We should leave it
> at that.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sys_chroot+sys_fchdir Fix
On Wed, 26 Sep 2007 20:04:14 +0930 David Newall <[EMAIL PROTECTED]> wrote: > Al Viro wrote: > > Oh, for fsck sake... Folks, it's standard-required behaviour. > > Ability to chroot() implies the ability to break out of it. Could > > we please add that (along with reference to SuS) to l-k FAQ and be > > done with that nonsense? > > I'm pretty confident that it's only standard behavior for Linux. > Every other unix says it's not allowed. So how about reading up on the subject instead? *spends five minutes with Google* >From the OpenBSD FAQ (an operating system most know for being really, really focused on security): http://www.openbsd.org/faq/faq10.html Any application which has to assume root privileges to operate is pointless to attempt to chroot(2), as root can generally escape a chroot(2). Solaris: http://www.softpanorama.org/Solaris/Security/solaris_privilege_sets.shtml You must be root to make the chroot() call, and you should quickly change to non-root (a root user can escape a chroot environment, so if it's to be effective, you need to drop that privilege). A chroot FAQ: http://www.unixwiz.net/techtips/chroot-practices.html There are well-known techniques used to escape from jail, but the most common one requires root privileges inside the jail. Another chroot FAT one linked to from the previous one: http://www.bpfh.net/simes/computing/chroot-break.html This page details how the chroot() system call can be used to provide an additional layer of security when running untrusted programs. It also details how this additional layer of security can be circumvented. Whilst chroot() is reasonably secure, a program can escape from its trap. Yet Another FAQ, this time about secure Unix Programming: http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/ chroot() only limits the file system scope and nothing else. [further descriptions of how to break out of chroot, with and without root privileges] Convinced? /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reiser4. BEST FILESYSTEM EVER.
[EMAIL PROTECTED] writes: > Lennart. Tell me again that these results from > > http://linuxhelp.150m.com/resources/fs-benchmarks.htm and > http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm > > are not of interest to you. I still don't understand why you have your > head in the sand. Oh, for fucks sake, stop sounding like a broken record. You have repeated the same totally meaningless statistics more times than I care to count. Please shut the fuck up. As you discovered yourself (even though you seem to fail to understand the significance of your discovery), bonnie writes files that consist of mostly zeroes. If your normal use cases consist of creating a bunch of files containing zeroes, reiser4 with compression will do great. Just lovely. Except that nobody sane would store a lot of files containing zeroes, except an an excercize in mental masturbation. So the two bonnie benchmarks with lzo and gzip are totally meaningless for any real life usages. As for the amount of disk needed to store three kernel trees, the figures you quote show that Reiser4 does tail combining where the tail of multiple files are stored in one disk block. A nice trick that seems save you about 15% disk space compared to ext3. Now you have to realise what that means, it means that if the disk block containing those tails (or any metadata pointing at that block) gets corrupted, instead of just losing one disk block for one file, you will have lost the tail for all the files sharing that disk block. Depending on your personal prioritites, saving 15% of the space may be worth the risk to you, or maybe not. Personally, for the only disk I'm short on space on, I mostly store flac encoded images of my CD collection, and saving 2kByte out of every 300MByte disk simply doesn't make any difference, and I much prefer a stable file system that I can trust not to lose my data. You might make different choices. The same goes for just about every feature that you tout, it has its advantages, and it has its disadvantages. Doing compression on data is great if the data you store is compressible, and sucks if it isn't. Doing compression on each disk block and then packing multiple compressed blocks into each physical disk block will probably save some space if the data is compressible, but at the same time it means that you will spend a lot of CPU (and cache footprint) compressing and uncompressing that data. On a single user system where the CPU is mostly idle it might not make much of a difference, on a heavily loaded multiuser system it might do. Logs can be compressed quite well using a block based compression scheme, but the logs can be compressed even better by doing compression on the whole file with gzip. So what's the best choice, to do transparent compression on the fly giving ok compression or teaching the userspace tools to do compression of old logs and get really good compression? Or maybe disk space really isn't that important anyway and the best thing is to just leave the logs uncompressed. Another example: one of the things Reiser3 is supposed to be really good for is storing an INN news spool, doing tail merging of lots of individual files containing articles gives a great space saving, and since it's just a news spool, reliability in face of a system crashes really don't matter all that much. On the other hand, INN's Cyclic News File System running on top of ext2 is probably an even better choice in that case. What do you want to use? What I want to get at is that you can troll the mailing lists (and crossposting stupid inflammatory material with an inane subject to a bunch of mailing lists the way you have done definitely is trolling) trying to say that whatever you're trying to sell is the best, but at the end, if a file system is better or not is a lot more complex than quoting just one benchmark (which, once again, is meaningless, compressing a lot of zeroes is simple and really does not tell you anything about real world usages). And there are other considerations too, even if Reiser4 would be the best thing since sliced breadd, can I trust Hans Reiser to support Reiser4 for the next five years? Or will he drop support for Reiser4 the same way he dropped support for the old Reiser3 when Reiser4 came along? Or will he drop Reiser4 when the grant to do Reiser 4 development expires? /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Greg KH <[EMAIL PROTECTED]> writes: > Or perhaps your device just needs to add some flow control to it :) Physical processes are hard to pause. :-) But yes, adding a 16kByte FIFO before the FT245 would have made life so much easier for me, but unfortunately the thing that drives the hardware choice is cost, cost and cost. /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Greg KH <[EMAIL PROTECTED]> writes: > Why would a userspace driver not work out for this. We already can > saturate the USB bus with a userspace program That is unfortunately not quite true. I have a (unfortunately proprietary) driver for a USB device that simply cannot be implemented in userspace. The USB device is a measurement device that pushes close to 800 kBytes/second of data through a FT245 chip. The measurement device does no flow control at all, it just presents a sample every 125 us to the FT245 and with only 256 bytes of buffer in the FT245 the only way to handle that is to have two URBs in flight at the same time, and I haven't found any way to do that in a robust and non-racey way from userspace. So the comment "The USB subsystem has changed a lot over time, and it has been possible to create userspace USB drivers using usbfs/libusb/gadgetfs that operate as fast as the USB bus allows." from feature-removal-schedule.txt is wrong I think. :-( Personally I'd much prefer to release the driver as open source, but as a consultant you don't get to decide what the customer does. So now they sit there with a driver that warns them that it'll stop working after february 2008. On a different topic, my personal pet peeve is USB scanners. There seems to be just a handful of different manufacturers of chips used in USB scanners: Realtek and Genesys covers 90% of the scanners. The SANE team has done a wonderful job of reverse engineering a lot of scanners, but the models change so fast that there seems to be no chance of keeping up. If the chip manufacturers just released specs for their chips and the scanner manufacturers could then document what settings to use Linux could have support for almost all USB scanners on the market, and it would probably cost them very little to do that. If I could find a good (4800-9600 dpi) scanner which said "supported by SANE" on the box I'd buy it immedately. /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND
Linus Torvalds <[EMAIL PROTECTED]> writes: > I never use SOFTWARE_SUSPEND, and I think the whole concept is totally > broken. > > Sane people use suspend-to-ram, and that's when you need the suspend and > resume debugging. > > Software-suspend is silly. I want my machine back in three seconds, not > waiting for minutes.. Suspend-to-disk has a few advantages over suspend-to-ram: With suspend-to-disk I can remove the battery (to put in a fresh battery when traveling), try doing that with suspend-to-ram. It's also really useful for my moving my old Thinkpad which has a battery which is so bad it can't even hold power for suspend-for-ram for more than a few seconds. With suspend-to-disk I can suspend Linux, resume Windows to be able to run that one program I have to run under Windows, suspend Windows and resume Linux again without having to restart alla applications. And yes, this have been very useful for me in real life. So it's really nice to have both suspend-to-disk and suspend-to-ram. /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
bert hubert <[EMAIL PROTECTED]> writes: > On Sun, Apr 10, 2005 at 03:38:39PM -0700, Linus Torvalds wrote: > > > compressed with zlib, they are all named by the sha1 file, and they all > > Now I know this is a concious decision, but recent zlib allows you to write > out gzip content, at a cost of 14 bytes I think per file, by adding 32 to > the window size. This in turn would allow users to zcat your objects at > ease. > > You get confirmation of completeness of the file for free, as gzip encodes > the length of the file at the end. I would very much like it if git used normal gzip files with a .gz extension. Doing it this way means that the compression methods can be extended in the future. I.e: ab/1234567890.gzgzip compressed ab/1234567890.xdxdelta compressed I find the xdelta encoding very attractive since it can probably reduce the size of the repository drastically. A compression script could for run nightly and xdelta compress everything that's older than a few months (to figure out what files to create the delta from, just look at the commit files and compare the parent tree to the current tree). Of course, this means that a dumb wget won't work all that well to synchronize two trees, but it might be worthwile anyways. /Christer -- "Just how much can I get away with and still go to heaven?" Freelance consultant specializing in device driver programming for Linux Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
In article <[EMAIL PROTECTED]> I wrote: >The only problem I can see with this is that it removes one useful thing, >the ability to give a user access to a whole partition. > >chown wingel /dev/hda5 > >won't work anymore since there is no such device node. Apologies, this should have gone to linux-fsdev, I entered the mail address by hand and by reflex typed the wrong thing. *going back to sleep* /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code inuserspace
In article <[EMAIL PROTECTED]> you write: >3. Userspace partition code proposal > > Given the above two bits, here's a brief explaination of a > proposal to move management of the partitioning scheme into > userspace, along with portions of raid startup, lvm, uuid and > mount by label code needed for mounting the root filesystem. > > Consider that the device node currently known as /dev/hda5 can > also be viewed as /dev/hda at offset 512000 with a limit of 10GB. > With the extensions in fs/block_dev.c, you could replace /dev/hda5 > with /dev/hda/offset=512000,limit=1024000. Now, by putting > the partition parsing code into a libpart and binding mount to a > libpart, the root filesystem mounting code can be run out of an > initrd image. The use of mount gives us the ability to mount > filesystems by UUID, by label or other exotic schemes without > having to add any additional code to the kernel. The only problem I can see with this is that it removes one useful thing, the ability to give a user access to a whole partition. chown wingel /dev/hda5 won't work anymore since there is no such device node. /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Alan Cox wrote: >At most it bounds the busses directly available. I've yet to see VME cardbus >adapters but its quite possible. You didn't try google did you? *grin* http://www.ramix.com/products/busadapters/rm235m.html /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BTTV detection broken in 2.4.0-test11-pre5
In article <[EMAIL PROTECTED]> you write: >On Sun, 19 Nov 2000, Alexander Viro wrote: >> On Sun, 19 Nov 2000, David Lang wrote: >> > there is a rootkit kernel module out there that, if loaded onto your >> > system, can make it almost impossible to detect that your system has been >> > compramised. with module support disabled this isn't possible. >> Yes, it is. Easily. If you've got root you can modify the kernel image and >> reboot the bloody thing. And no, marking it immutable will not help. Open >> the raw device and modify relevant blocks. > >Kernel on writeprotected floppy disk... So change the CMOS-settings so that the BIOS changes the boot order from A, C, CD-ROM to C first instead. *grin* How long do you want to keep playing Tic-Tac-Toe? Of course, using capabilities and totally disabling access to the raw disk devices and to any I/O ports might be the solution, provided that there are no bugs or thinkos in the capabilities code. /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CONFIG_EISA note in Documentation/Configure.help
[Ouch, I tried to mail this to vger.rutgers.edu again, alan, sorry for the duplicate mail.] In article <[EMAIL PROTECTED]> you write: >Some clues here > >http://www.google.com/search?q=cache:www.korpse.freeserve.co.uk/hardware/pnp/html/escd.html+eisa+data+format&hl=en > >but the original seems to have gone from korpse 8( > >Microsoft have escd.rtf that documents the escd in terms of eisa records thus >gives clues I have the EISA documentations on paper somewhere (I just moved house and things are still a mess), so if you have any specific questions about the EISA configuration formats, I can probably find the binder and look it up for you. /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Proposal: Linux Kernel Patch Management System
> Here is a proposal to improve the kernel development process. It was > co-written by Sebastian Kuzminsky, Linus Torvalds, Theodore Ts'o, and > myself. We are posting the proposal here for public review and > comment. Seb is the guy writing on the software; he's nearly done the > initial version. What you are actually trying to do is to implement a feature-based software configuration management system. >Required tags: > > "Version" - the base kernel version. For example, "2.4.0-test8-pre1". > The web page will list valid version strings. Note that this could just as well be the first item on Requires tag. For example, each Linux kernel would need the one before it: linux-2.2.17 requires linux-2.2.16 which requires linux-2.2.15 etc. > "Requires" - followed by one or more kernel-patch identifiers. >For example, "KP7555". Rembember that the ordering of the Requires tag is quite important if there are multiple patches modifying the same files. Currently I'm working on a kernel which is based on linux-2.2.16 and also has the backport of the USB code from linux-2.4.something, a patch with a driver for a device, and yet another patch for something else. Most of these patches are not dependent on each other really, but a few of them touch the same files which makes things a bit complicated. It would be very nice if the creator of the patch could give the patch some kind of "base name", as it'll be Alexander S A Kjeldaas wrote, it's much easier to understand what "geode-irq-fixup-12" means than "KP3712". Maybe this should be called a "Feature" instead of base-name, because that's what it is, the patch implements a feature. A very nice tool to have would be an automatic patcher where I say "I want this patch, get everything it needs" and which then performs all the patching. Say that I'm working on an USB driver for the National Semiconductor Geode which is currently based on the following stuff: linux-2.2.14 usb-2.3.99-pre7-1-for-2.2.14 (requires linux-2.2.14) wingel-usb-12 (requires usb-2.3.99-pre7-1-for-2.2.14.diff) So if I say "I want the wingel-usb-12" version, it'll download and patch everything in order. (Actually, the wingel-usb-12 patch might even be empty, the only thing I'm using it for is to select which set of features/patches I want.) A few things to thing about here, what should happen if I upgrade the Linux kernel to 2.2.16? I should be able to patch it with the usb patch for 2.2.14 since the tool should be able to tell that linux-2.2.16 is a successor of linux-2.2.14, but at the same time it should tell me that I'm trying to do an imperfect patch (which might result in rejects) and not allow me to do this automatically. What I'd have to to is to apply the patch manually and create a new usb-2.3.99-pre7-1-for-2.2.16 patch instead. This will of course force me to create a new wingel-usb-13 patch too. linux-2.2.16 (obsoletes linux 2.2.14-15) wingel-usb-2.3.99-pre7-1-for-2.2.16 (requires linux-2.2.16 and obsoletes usb-2.3.99-pre7-1-for-2.2.14) wingel-usb-13 (requires usb-2.3.99-pre7-1-for-2.2.16 and obsoletes wingel-usb-12) Actually, the tools could have a few more goodies. While I've been waiting the guy doing the usb backport has released a new version which based on a newer 2.4 kernel and is relative to the 2.2.16 kernel, so what I'd really like is to use that patch instead. The tools would probably have to do some interesting backtracking to figure out that usb-2.4.0-for-2.1.16 is related to my wingel-usb-2.3.99-for-2.2.16 through a common ancestor usb-2.3.99-for-2.2.14. linux-2.2.16 usb-2.4.0-test2-pre2-for-2.2.16-v3 (requires linux-2.2.16 and obsoletes usb-2.3.99-pre7-1-for-2.2.14) wingel-usb-14 (requires usb-2.4.0-test2-pre2-for-2.2.16-v3 and obsoletes wingel-usb-13) I belive that linux-2.2.17 includes the usb-2.4 backport, so if I do that move I'll end up with: linux-2.2.17 wingel-usb-14 (requires linux-2.2.17) It would be nice if the tracking of the usb code doesn't disappear when it's incorporated into the kernel, since a new backport might be needed in the future, but I'm not sure if that is possible. I think I've written too much again, but I've been thinking and reading about the same thing for quite a while and just wanted to do a brain-dump of what I've been thinking of. Comments? /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Masking out one page of RAM because of bit-errors.
In article <[EMAIL PROTECTED]> you write: >Dear list-readers, >I have a bad SDRAM chip with exactly one bit error. Memtest86 shows >that the bit error always occurs at the address 0x4eff508. I tried >to calculate the page number and it should be 20223. ... >Could someone tell me if there's another way to mark this single page >as unusable ? This ought to work. Put the code somewhere at the end of mem_init() in arch/i386/mm/init.c long addr = 0x4eff508; set_bit(PG_reserved, &mem_map[MAP_NR(addr)].flags); This is for linux-2.2.16 , I don't know if it works with 2.4. /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
In article <[EMAIL PROTECTED]> you write: >I'm really kind of surprised that companies like SuSE, VA and RedHat >haven't started talking about forking the kernel already. Those companies >are serving the administrators and managers whose needs you are openly >admitting that you are not concerned with. For those companies the >present state of affairs isn't sustainable. If you haven't noticed, they already do. The kernel shipped from RedHat has quite a few patches applied that arent in Linus' tree. There's nothing stopping them from doing the same thing with the KGDB or IKD patch. /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
