Kernel Traffic #53 For 7 Feb 2000

Rest assured that it won't. While the patch from v2.0.38 to v2.0.39 *will* be somewhat larger than v2.0.37 to v2.0.38, the changes will be almost as minimal. No new features.

v2.0.39pre1 is 5160 bytes. v2.0.39pre2 is, at the moment (not yet finalised) 167075 bytes, and will probably not grow much further. 2979 bytes of the diff touches code (and that includes the diff context), the rest is white-space changes, changes of Documentation, CREDITS, MAINTAINERS, whitespace, backporting of a code-page 8859-14 and some other text-fixes.

The only thing I consider adding now is a change to the Makefile to add an extra-version during the pre-patches.

I'm just proposing to shorten the devel cycle not by simply reducing the time between the first releaase of 2.5.0 and the final of 2.6.0, which may be a bad thing, but just letting it overlap with the previuos cycle of 2.3 - 2.4. Numbers means nothing in this context, but let's see an example. Given a devel cycle on 12 months, we have now a stable release every year, roughly this way:

3 months of wild changes/core rewriting - 3 months of porting the rest of the kernel to the new API - 3 months making it stable - RELEASE 3 months of fixes - SPAWN of new devel.

I'm just proposing to have two overlapped cycles, about 6 months apart: just spawn the new devel when you're at the pre-release step. This way there's always a place to put development code, with no need to way or to develop against stable releases... and there's also less pressure on including "new" features on a nearly stable kernel.

Yes, having two cycles means double work. But also developing against 2.2 and then "backporting" to 2.3 is also double work...

The points are:

1. there's an huge demand of new features in a soon-to be-released kernel, because everybody knows that we have to wait almost a year for the following release. I don't mean this pressure comes from end users only. Commercial distributions should take care of them (and they do). But also developers want their work to be released as part of the standard kernel, sooner or later. See pressure on relaxing the meaning of a 'feature-freeze' or 'stable kernel'. And that's not just ego: a large user base is required for the final debugging phase, to produce rock-stable software. This pressure tends to delay further the final release of new kernels, short-circuiting to 1).
2. as a reaction to 1), some developers go on indipendently, expecially if their devel-cycle di out of sync with Linus' one. If they're at 30% of the initial implementing phase when Linus calls a feature-freeze, right now they have no other choice, if they want to go on working. Since it makes a lot of sense for them to keep their patches up to date with kernel patchlevels, in the end they find themselves working on the lastest *stable* kernel, say 2.2. Eventually, when they're at 95% of development, and need some extensive testing, they make a public release. A new feature appears for a *stable* kernel. Meanwhile, the new main kernel devel branch (2.3) appears. If it does not break their code, they're lucky, and may go on in fixing bugs, and have a stable piece of software on 2.2 and (with little effort) on 2.3 (later on 2.4). But changes in 2.3 may even force them to choose: either go back to implementation phase (or even re-design something), throwing away some or most of the work already done, or ignore 2.3 and go on debugging. The first choice is the best in the long term, of course, since they get in sync with the main kernel development cycle, but i think most would choose the second one, and i don't blame them for that. We end up with a feature thats work great on 2.2 and is not there on 2.3. This too raises the pressure on delaying 2.3/4, short-circuiting to 1) again.

3. Pressure in 2) in not just a lot of messages posted on this list in "I want this/that" threads. It's also that: "i do want to do some testing, but since i need/like feature 'X' that is a 2.2 only thing, i can't test 2.3", while it should be right the opposite: "if you want the cool feature 'X', you have to help in testing 2.3". This slows down the process of getting 2.3 to 2.4. Sorry, this slows down *A LOT* the process.

   Just imagine that the new RAID and ReiserFS are available for 2.3 only (and that they work together B-)). To make a public release of them, both Redhat and Suse (to name just two) should put much effort on getting some 2.3.xx stable enough to be released. This leads necessarily to a faster development of 2.3.

   Right now 2.3 has less features that 2.2. That's not only because of its internal changes that broke drivers/modules/fs's and the like (that's part of the devel process) but also because some features were developed on 2.2, when 2.3 was not available.

Having an earlier appearance of the 2.5 branch, say before 2.4.0, will probaly lead to other problems (e.g. Linus and other being overloaded, the press being confused), but will help solving 1), 2) and 3) now, and, above all, avoiding they happen again for 2.5 itself, IMHO. I don't understand if you think that 1), 2) and 3) are not happening, or you don't see them as problems, or you don't think that my idea on facing them is good...

It has that label because the feedback is so light.......... Until more positive reports come in or I get some more hardware to do verification tests upon, that is defined as (EXPERIMENTAL).

Use it and complain, boast, or nothing.........being a bench warmer will continue the status of "EXPERIMENTAL".

Sort of: If you get 0 "it didn't work for me" reports that could be because 0 people actually tried it. However, now we know at least two people tried it.

I suggest that you still want to know both for whom it works and for whom it doesn't work! If you have the hardware: Shout!

Regardless of how important you consider each country is, they are always important for those who live there...

But I'd bet that for instance China has crypto-laws (no, I don't know if this indeed is true; it's merely a guess, depending on their political system), and China has the world's largest population, is a growing, prospering economy (now that they slowly approach market-economy), and has a rapidly growing Linux userbase.

Oh, and I'd consider Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria (the "horrible" 7, that the US seem to fear more than death itself), more than enough reason not to put crypto into the kernel.

Would you want to barr off even one of the kernel-developers, when there's already a perfect legit way of spreading the crypto-code. While it's pretty probably none of the kernel-developers come from the "horrible" 7 (at least, there were none in the CREDITS-file in v2.3.39), there may be more countries that get barred off.

Those people who don't know how to recompile a kernel, buy or download a distribution and the kernel that comes with it. Almost every distro that I know of has some kind of mirror where you can download software banned in the States (crypto, patent-encumbered stuff, etc.), and for those who _do_ know how to compile a kernel, ftp.kerneli.org is the perfect place to visit. What we need is simply the distro-makers to start compiling crypto-support into their kernels as default (only the international versions, of course), and provide them from a server somewhere.

However, if it proves itself that the change of mind in the US indeed is as good as it seems, we could start distributing the kerneli-patches from ftp.kernel.org too. Those mirrors who then aren't allowed to import crypto simply can exclude one directory (I'm no expert on rsync/mirroring or whatever is used, but I believe it's possible, correct me if I'm wrong.)

I think that we have to realise, that the big problem is not whether it's allowed to USE crypto in a country, or if it's allowed to IMPORT crypto. Almost no countries have such regulations. But a lot of mirrors of ftp.kernel.org might have to close down if we put stuff that is illegal to EXPORT into the kernel.

IANAL, but from my review of the Swedish regulations on crypto, for instance, it wouldn't be possible to redistribute the ikernel-patches from Sweden once imported. While the probability of anyone giving a damn here in Sweden is minimal (considering how easy it seems to export weapons from Sweden...), there are other countries that might be harder.

According to Intel Manual 24319201.pdf (S/W Vol 3) Section 3.7, pg 3-27, there are only 2 ways to invalidate a global page:

• use the INVLPG instruction with the address of the specific translation, or
• first turn off the PGE flag in CR4, then (re)write CR3, then restore CR4.

This may be intentional for some uses of __flush_tlb(), but there are several places where Linux attempts to flush TLB entries for global pages, such as in the smp boot code.

I've been getting tons of email about the trademark thing due to the action of stopping the auctioning off of linux-related names, so instead of just answering individually (which was how I started out), I'll just send out a more generic email. And hope that slashdot etc pick it up so that enough people will be reassured or at least understand the issues.

And hey, you may not end up agreeing with me, but with the transmeta announcement tomorrow I won't have much time to argue about it until next week ;)

Basically, the rules are fairly simple, and there really are just a few simple basic issues involved:

• I (and obviously a lot of other people) do not want to have "Linux" as a name associated with unacceptable (or borderline) behaviour, and it's important that "Linux" doesn't get a name of being associated with scams, cybersquatting, etc etc. I'd personally hate that, for rather obvious reasons. I _like_ being proud of Linux, and what has been achieved. I'd rather not have to apologize for it..

• Trademark law requires that the trademark owner police the use of the trademark (unlike, for example, copyright law, where the copyright owner is the copyright owner, always is, and always will be unless he willingly relinquishes ownership, and even THEN he ends up having rights).

  This is nasty, because it means, for example, that a trademark owner has to be shown as caring about even small infringements, because otherwise the really bad guys can use as their defense that "hey, we may have misused it, but look at those other cases that they didn't go after, they obviously don't care.."

• Even with things that aren't scams or something like that, VALID uses of "Linux" may be bad if they mean that other valid uses of "Linux" are blocked.

Those are the kind of ground rules, I think everybody can pretty much agree with them..

What the above leads to is

• I'm required to ask people to acknowledge the trademark. When you use the term "Linux" in official marketing literature etc, you should acknowledge it as a trademark owned by me. Not because I love seeing my name in print, but simply because of the "policing" issue (#2) above.

  (And no, that does NOT mean that you have to add that to normal, everyday use of the term. Common sense rules the day, think of the situations where you see the silly "xxxx is a trademark of yyyy", and realize that yyyy may not really care except the legal issues force them to ;)

• _Intent_ matters. It matters a lot.

  If your intent is to use the word "linux" as part of a real Linux project, that doesn't mean that you automatically absolutely have to get permission from me. That's the LAST thing I want. I want "Linux" to be as free as possible as a term, and the real reason for having a trademark in the first place was to _protect_ it rather than use it as some kind of legalistic enforcement thing.

  But, for example, if your intent is to register "mylinux.com" (made up example, I don't know if it is registered or not) only in the hopes of selling the domain name for mucho dinero later, then that kind of intent is not something I (or anybody else, I think) would find really acceptable, because now the use of "linux" in this case has really been a question of blocking somebody ELSE from using the term and using it to get money.

  This is where the cybersquatting laws come in, for example, allowing the use of a trademark as a way to make sure that such squatting activity does NOT happen.

• Being "specific" is _good_. Being specific largely avoids the problem of many people/organizations wanting the same name. We had an example long ago of somebody who would have wanted to register "Linux Expert" as a servicemark, yet obviously that is a pretty generic term. Not good, if it means that there will be confusion about who owns the term.

  In contrast (to give some tangible examples), something like "VA Linux" or "Red Hat Linux" oviously isn't a generic term: it's a very _targeted_ term for something very specific. Those kinds of names do not detract from other peoples ability to call _their_ Linux company something else.

• Finally, you have to judge the "officialdom" and the importance of the business side of your usage. Not because I or anybody else really cares all that much, but more because of the "pain factor" if the name is asked for by somebody else.

  Basically, ask yourself the question: "What if somebody else had a project, and happened to chose the same name for his project as I have for mine, how strong a protection do I want for MY version of the project?"

  Also, ask yourself: "Would anybody ever have reason to question the name, and do I need to make provisions for protecting this particular instance of it" (and note that "anybody" may not be me as the trademark owner myself, but it may be a competitor who wants to make life uncomfortable for you)

  If you decide that you want some official protection from the mark, that probably means that you want to own your own version of the trademark, ie a "service mark" or a "combination mark". There are obvious cases where such a thing is wanted - you should not be surprised to hear that various Linux companies own their own combination marks, or have at the very least gotten that ownership verbally approved by me pending getting the paperwork done.

So basically, in case the trademark issue comes up, you should make your own judgement. If you read and understood the above, you know pretty much what my motivation is - I hate the paperwork, and I think all of this is frankly a waste of my time, but I need to do it so that in the future I don't end up being in a position I like even less.

And I'm _not_ out to screw anybody. In order to cover the costs of paperwork and the costs of just _tracking_ the trademark issues (and to really make it a legally binding contract in the first place), if you end up going the whole nine yards and think you need your own trademark protection, there is a rather nominal fee(*) associated with combination mark paperwork etc. That money actually goes to the Linux International trademark fund, so it's not me scalping people if anybody really thought that that might be the case ;)

I hope people understand what happened, and why it happened, and why it really hasn't changed anything that we had to assert the trademark issue publically for the first time this week. And I hope people feel more comfortable about it.

And finally - I hope that people who decide due to this that what they really want is trademark protection for their own Linux trademark, that they could just wait a week or two, or contact maddog at Linux International rather than me. We're finally getting the shroud of secrecy lifted from transmeta (hey, we'll have a real web-site and zdtv is supposed to webcast the announcement tomorrow), and I'd rather worry about trademarks _next_ week.

Ok?

(*)("Nominal fee". What an ugly sentence. It's one of those things that implies that if you have to ask, you can't afford it. In reality, it's more a thing where both intent and the size of the project will make a difference - and quite frankly it's also a way to slightly discourage people who aren't really serious about it in the first place.)

I have just gotten access (through the place I work, which will have to remain 'nonymous) to a fully-loaded Compaq 8500 with 8 Xeon 550Mhz processors (yep, eight of em) with 1MB of cache each and 4GB of RAM along with the usual Big Compaq Server goodies like the latest Compaq SMART RAID controller and some flavor of dual-100Mbps Ethernet/Gigabit fibre network adapter type thing.

The exciting thing (for me anyway) is that it is currently running RedHat 6.1, although with caveats: we haven't gotten it to use more than the first 2GB of RAM yet and the NIC is pretty finicky at 100Mbps and we haven't gotten the fibre channel working yet either. It does, however use all 8 processors without a problem, which lets it compile the kernel in like 35 seconds. I'm going to try to get the latest 2.3 kernel running on it tomorrow.

If there are kernel development things that will really take advantage of a monster machine like this for testing, please don't hesitate to let me know. Of course, I can't give anyone access to the machine directly, but I am more than willing to run experiemental stuff on it. (Within limits, of course.) It's also in a lab environment so we have many client machines on a switched network we can use to pound on it for load testing situations.

We have a similar machine(Dell 6300) but currently with 4 cpus instead of 8. You need 2.3 in order to use all of your memory, when you config you can select 4GB.

BTW, Our 6300 ran 2.3.35 fine but 2.3.36 - 2.3.39 had problems booting with all 4 cpus. I just grabbed 2.3.40 and I will try it soon.