From: torv...@transmeta.com (Linus Torvalds)
Subject: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <Pine.LNX.3.95.980423232102.1919H-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 347226700
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
I just released a fairly small patch to 97 to bring it up to 98.
I've gotten a lot of patches in the mail for the last week, and I've been
ignoring most of them for obvious reasons. They aren't in any in-queue,
you can more-or-less consider them lost - but don't resend them all
immediately, because if I get another huge batch of patches then I'll just
have to ignore them again.
We're going slow and easy, and the plan is to not only keep me sane in the
midst of all the diapers, but I'll also at the same time take the
opportunity to actually enforce the feature-freeze. You've known about it
for a long time, _tough_.
Anyway, 2.1.98 _should_ fix:
- the IDE/SCSI lockups. The irq enable/disable code was broken, and could
do some really bad things. This tended to lock up the machine if you
accessed your IDE disks heavily, or in particular if you had a mixture
of IDE and SCSI and used them at the same time. Tell me if you still
have problems - I'm sure there are still bugs left, and I want to hear
about them.
- memory management especially on small-memory machines. I think I made a
good change to the allocation logic, and I'm hoping it will fix the bad
bahevaiour on those wimpy machines that all you losers out there are
using that have less than half a Gig of RAM. It certainly still works
fine on my machine, and I'm certainly still too lazy to test it out on
anything smaller.
There's a few other updates too: the asm constraints are fixed, so it
should compile again with other compiler versions than the particular one
I happen to be using. And some of the SCSI drivers have been updated a
bit.
There's been a lot of discussion and patches on capabilities, and I
haven't applied them yet, I'll let them simmer a bit. Similarly, I've seen
so many pathes to kmod that my head is spinning, and as I don't use
modules myself I'd really like to get feedback from users about the
different patches, so that maybe I'll get something that everybody can
agree on as acceptable. Right now I don't know which patch I should even
begin looking at.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <199804241106.EAA05412@dm.cobaltmicro.com>#1/1
X-Deja-AN: 347273472
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980423232102.1919H-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Date: Thu, 23 Apr 1998 23:30:18 -0700 (PDT)
From: Linus Torvalds <torv...@transmeta.com>
We're going slow and easy, and the plan is to not only keep me sane
in the midst of all the diapers, but I'll also at the same time
take the opportunity to actually enforce the feature-freeze. You've
known about it for a long time, _tough_.
Feature freeze is one thing, but totally ignoring all of the critical
networking bug fixes I tried to merge to you is yet another...
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: al...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <m0yShNp-000aNhC@the-village.bc.nu>#1/1
X-Deja-AN: 347315640
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199804241106.EAA05412@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
> in the midst of all the diapers, but I'll also at the same time
> take the opportunity to actually enforce the feature-freeze. You've
> known about it for a long time, _tough_.
>
> Feature freeze is one thing, but totally ignoring all of the critical
> networking bug fixes I tried to merge to you is yet another...
Give him a break Dave, he dropped all the sound fixes I sent him too and
the video4linux ones. Until Linus gets back on his feet its better that
folks just use the CVS tree Linux on vger.rutgers.edu
I've seen people with new children before, they go from ultra happy to
looking like something out of a zombie film in about a week.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <199804241329.GAA06564@dm.cobaltmicro.com>#1/1
X-Deja-AN: 347307395
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0yShNp-000aNhC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
From: al...@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 24 Apr 1998 13:15:12 +0100 (BST)
Give him a break Dave, he dropped all the sound fixes I sent him
too and the video4linux ones. Until Linus gets back on his feet its
better that folks just use the CVS tree Linux on vger.rutgers.edu
I know I know, smelly diapers and all that, but the point of all my
efforts lately have been to make a complete merge of the vger CVS tree
to Linus an actual reality, the timing is just shit at the moment I
suppose.
Saying each time "while Linus is in diaperville everyone just use the
CVS tree" is wrong, because it's nice for the moment and for the
developers who want to get their stuff in quickly "somewhere" (and
here is where the Linus model breaks down, there is no "somewhere" to
queue your patches in some semi-permanent manner, we've tried to do
that with vger for a while, but it breaks down) but later it's a pain
in the ass for me and for Linus because I have to split up 2MB of
diffs each round and get them to him cleanly, and worse yet some of
these patches end up overlapping so sending completely clean stuff is
an utter nightmare.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: al...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <m0ySiwz-000aNhC@the-village.bc.nu>#1/1
X-Deja-AN: 347332720
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199804241329.GAA06564@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
> Saying each time "while Linus is in diaperville everyone just use the
> CVS tree" is wrong, because it's nice for the moment and for the
> developers who want to get their stuff in quickly "somewhere" (and
I meant for people who wanted to _test_ current networking/sound/video
while Linus is out.
> here is where the Linus model breaks down, there is no "somewhere" to
> queue your patches in some semi-permanent manner, we've tried to do
> that with vger for a while, but it breaks down) but later it's a pain
> in the ass for me and for Linus because I have to split up 2MB of
> diffs each round and get them to him cleanly, and worse yet some of
> these patches end up overlapping so sending completely clean stuff is
> an utter nightmare.
There isnt an answer to this one unless Linus changes his way of working
and we find a way we can do that without losing the advantages of the Linus
Torvalds bogoid code filter or someone teaches him to use a condom ;)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: torv...@transmeta.com (Linus Torvalds)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <Pine.LNX.3.95.980424090329.2728D-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 347366886
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0yShNp-000aNhC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
On Fri, 24 Apr 1998, Alan Cox wrote:
> >
> > Feature freeze is one thing, but totally ignoring all of the critical
> > networking bug fixes I tried to merge to you is yet another...
>
> Give him a break Dave, he dropped all the sound fixes I sent him too and
> the video4linux ones. Until Linus gets back on his feet its better that
> folks just use the CVS tree Linux on vger.rutgers.edu
>
> I've seen people with new children before, they go from ultra happy to
> looking like something out of a zombie film in about a week.
Just to clarify: David sent me about ten patches in close succession with
nary _any_ explanation of any of the patches.
Quite frankly, I tend to ignore that kind of spam-mail even when I don't
have a new baby. If the submitter of patches cannot bother to tell what
the patches do and why I should apply them, I won't be bothering to apply
them.
Using the CVS tree is not going to help that.
Btw, Alan, I haven't even _seen_ your patches,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: al...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <m0ySkvu-000aNhC@the-village.bc.nu>#1/1
X-Deja-AN: 347366889
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980424090329.2728D-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
> have a new baby. If the submitter of patches cannot bother to tell what
> the patches do and why I should apply them, I won't be bothering to apply
> them.
>
> Using the CVS tree is not going to help that.
I did mean for testing
> Btw, Alan, I haven't even _seen_ your patches,
No problem, I was going to send you another set end of the weekend and see
if you'd recovered
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: torv...@transmeta.com (Linus Torvalds)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <Pine.LNX.3.95.980424092035.2728F-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 347384859
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0ySkvu-000aNhC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
On Fri, 24 Apr 1998, Alan Cox wrote:
>
> No problem, I was going to send you another set end of the weekend and see
> if you'd recovered
I have recovered fairly well: the new baby has been very wellbehaved
indeed, and I should be able to work at 60% efficiency or similar. I may
be more irritable than usual due to minor lack of sleep, and I also got
about 500 emails of congratulations (which I appreciate, but they did hide
other emails). But I can certainly apply patches if they are clearly the
right thing.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: j...@sunsite.ms.mff.cuni.cz (Jakub Jelinek)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <199804241738.TAA01629@sunsite.ms.mff.cuni.cz>#1/1
X-Deja-AN: 347397815
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980424090329.2728D-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
> Just to clarify: David sent me about ten patches in close succession with
> nary _any_ explanation of any of the patches.
>
> Quite frankly, I tend to ignore that kind of spam-mail even when I don't
> have a new baby. If the submitter of patches cannot bother to tell what
> the patches do and why I should apply them, I won't be bothering to apply
> them.
>
> Using the CVS tree is not going to help that.
I think the CVS could help: with every commit, there is a log message
telling the purpose of the commit.
It is just hard to send such descriptions in such bulk patches as David was
creating - they contain most of what has been written on vger since January
or whenever last full merge happened.
If you were in the CVS, you could decide on a daily basis which commits
should go out, which should be rewritten and which are just fine...
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | j...@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.97 on a sparc64 machine (498.80 BogoMips).
___________________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: torv...@transmeta.com (Linus Torvalds)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <Pine.LNX.3.95.980424113219.5321A-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 347448842
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199804241738.TAA01629@sunsite.ms.mff.cuni.cz>
Newsgroups: muc.lists.linux-kernel
On Fri, 24 Apr 1998, Jakub Jelinek wrote:
> >
> > Using the CVS tree is not going to help that.
>
> I think the CVS could help: with every commit, there is a log message
> telling the purpose of the commit.
I use CVS for work, and I know there is a commit message.
However:
- not everybody uses it. At work, we force people to use it by mailing
out the commit messages to an internal newsgroup, so everybody sees
when a commit doesn't have a good message. Without that kind of
pressure to write the message, the messages tend to be fairly bad, at
least as far as I have seen.
- the commit messages go into a big black hole, and never come back. You
_can_ get at them, but you certainly don't get them easily, and you
_definitely_ don't get them when you try to make a combination patch.
> If you were in the CVS, you could decide on a daily basis which commits
> should go out, which should be rewritten and which are just fine...
I _do_ use CVS - just not for the kernel - and I know its limitations.
CVS does _not_ support having separate branches very well. There is
support for branching, but it is by no means very good or very easy to
use.
It is non-trivial to get _only_ the changes that correspond to a certain
series of commits, and to leave out the changes that everybody else have
been doing. At least I haven't found anything to do anything like that.
In short, CVS is not _nearly_ good enough. Sorry,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: Linux-2.1.98..
Date: 1998/04/24
Message-ID: <199804241842.LAA14439@dm.cobaltmicro.com>#1/1
X-Deja-AN: 347448848
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980424113219.5321A-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Date: Fri, 24 Apr 1998 11:37:08 -0700 (PDT)
From: Linus Torvalds <torv...@transmeta.com>
However:
- not everybody uses it. At work, we force people to use it by mailing
out the commit messages to an internal newsgroup, so everybody sees
when a commit doesn't have a good message. Without that kind of
pressure to write the message, the messages tend to be fairly bad, at
least as far as I have seen.
We are anal about it on the Vger tree.
- the commit messages go into a big black hole, and never come back. You
_can_ get at them, but you certainly don't get them easily, and you
_definitely_ don't get them when you try to make a combination patch.
Not true, if you know how to set up a CVS repository correctly, I have
things hacked up on vger so this _DOES_ happen. For all types of
large combo patches etc, you can get the commit messages in there any
way you like.
It is non-trivial to get _only_ the changes that correspond to a certain
series of commits, and to leave out the changes that everybody else have
been doing. At least I haven't found anything to do anything like that.
In short, CVS is not _nearly_ good enough. Sorry,
Ted T'so uses the technique on some of his tree's of creating a branch
which is where most people play around, ever week or couple of weeks,
a merge process is done by the people who have write access to the
main line.
I don't know how well it would work for us.
Anyways, I've also been maintaining a 2.0.x stable branch on the tree
actively and it seems to work rather well. And some people who use
vger create their own branches when they aren't totally confident
about their changes, then after testing they merge their stuff into
the main line and remove thier "temporary" branch.
The EGCS folks have run into some issues with branching, and worked
them out from what I can tell, maybe we can get some tips from them.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: m...@shout.net (Michael Elizabeth Chastain)
Subject: Re: Linux-2.1.98..
Date: 1998/04/25
Message-ID: <199804250224.VAA21291@duracef.shout.net>#1/1
X-Deja-AN: 347485841
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
Hi guys,
This is a shot in the dark:
Maybe this failure in 'make dep' has something to do with the
following code in mkdep.c, which mmaps several bytes, and maybe
a page, *beyond* the end of the file:
mapsize = st.st_size + 2*sizeof(unsigned long);
mapsize = (mapsize+pagesizem1) & ~pagesizem1;
map = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, fd, 0);
This enables the character-reading state machine to run with
a very fast inner loop, but I don't know if mapping beyond the
end of the file -- perhaps even into a new page -- is valid.
Again, just a shot in the dark.
Michael Chastain
<mailto:m...@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: Linux-2.1.98..
Date: 1998/04/25
Message-ID: <199804250247.TAA24636@dm.cobaltmicro.com>#1/1
X-Deja-AN: 347488856
Approved: ge...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199804250224.VAA21291@duracef.shout.net>
Newsgroups: muc.lists.linux-kernel
Date: Fri, 24 Apr 1998 21:24:53 -0500
From: Michael Elizabeth Chastain <m...@shout.net>
This enables the character-reading state machine to run with a very
fast inner loop, but I don't know if mapping beyond the end of the
file -- perhaps even into a new page -- is valid.
Under Linux it is allowed, and always has been allowed. When you run
off the end, you get zero filled pages.
Some OS's like Solaris etc. send you a segfault when you do this.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu