Andreas Haumer wrote:
>
> Keith Owens wrote:
> >
> > I worry about anything that increases the on disk size of bzImage, even
> > if the extra data does not get loaded into kernel memory.
> >
> You also have to consider filesize restrictions with some
> network bootproms loading the kernel image w
Keith Owens wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > I'd just like to remind you of Alan Cox's suggestion about appending
> > .config.gz to bzImage so that it doesn't get loaded into memory, and
> > my suggestion to put System.map.gz there
Marc Lehmann wrote:
>
> On Sat, Sep 16, 2000 at 10:59:54PM +0200, Daniel Phillips
><[EMAIL PROTECTED]> wrote:
> > Here we are, finally: code. I do not make any claim that this code is
> > elegant, correct, complete, esthetically pleasing or that it will
> > r
Keith Owens wrote:
> On Wed, 20 Sep 2000 17:09:27 +0800 (CST),
> <[EMAIL PROTECTED]> wrote:
> >I would like to upgrade my kernel which is bundled with Red Hat.
>
> Ask redhat for the .config, this is not a problem for the linux-kernel list.
I'd just like to remind you of Alan Cox's suggestion ab
Daniel Phillips wrote:
> Alexander Viro wrote:
> > On Tue, 19 Sep 2000, Daniel Phillips wrote:
> >
> > > !Mapped, !Uptodate, Dirty: pending map and write
> >
> > Wrong. It's an instant BUG at line 711 in ll_rw_blk.c - remember these
> > repor
Alexander Viro wrote:
>
> On Tue, 19 Sep 2000, Daniel Phillips wrote:
>
> > The more I think about it the less clear and ambiguous I find it.
> > When you add the dirty bit into the pot you get:
> >
> >Mapped, Uptodate, Dirty: not possible
>
>
Linus Torvalds wrote:
>
> On Mon, 18 Sep 2000, Alexander Viro wrote:
> > * we have several bh state components and the thing is a big,
> > fscking mess. If we look at the areas outside of the page lock we have:
>
> It's not a mess at all.
>
> I don't see why you call things "first stage"
Andreas Dilger wrote:
>
> Daniel writes:
> > Alexander Viro wrote:
> > > On Mon, 18 Sep 2000, Andreas Dilger wrote:
> > > > This may actually be a problem in the future... what about shared access
> > > > block devices like FCAL or a distributed filesystem? It has to be
> > > > possible for page
Linus Torvalds wrote:
>
> On Mon, 18 Sep 2000, Alexander Viro wrote:
> > That's what makes me unhappy about the current situation + obvious
> > fixes. It works, but the proof is... well, not pretty.
>
> Oh, agreed. I think we should clean up the code. I looked at it yesterday,
> and it did
Alexander Viro wrote:
>
> On Mon, 18 Sep 2000, Andreas Dilger wrote:
>
> > Alexander writes:
> > > * uptodate pages should never become non-uptodate.
> > > uptodate .. pages ... never have data _older_ than on disk
> >
> > This may actually be a problem in the future... what about sh
Alexander Viro wrote:
>
> On Sun, 17 Sep 2000, Linus Torvalds wrote:
>
> > On Sun, 17 Sep 2000, Alexander Viro wrote:
> > >
> > > Looks sane. But I really wonder if we could just do it in
> > > create_page_buffers() if page is up-to-date. OTOH it would require attempt
> > > to map them all.
Here we are, finally: code. I do not make any claim that this code is
elegant, correct, complete, esthetically pleasing or that it will
refrain from eating your hard disk.
What this code will do is let you verify for yourself whether my
proposed approach to tailmerging for Ext2 is worth the effo
Keith Owens wrote:
> * Standardize on tracking the System.map and .config with the kernel.
There was a suggestion from Alan Cox that .config.gz be appended to
bzImage, after the part that gets loaded into memory, to which I added
the suggestion that System.map.gz also be appended. That about tak
Andi Kleen wrote:
>
> On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
> > The hardest problem: how do you do the block read? Possibilities:
> >
> > - Ignore the problem, use normal block device I/O
> > - Use the real mode bios, needs V86 suppo
Marco Colombo wrote:
> BTW, a kernel debugger *is* available. And maybe even a more powerful
> one will be if Jeff decides to port and publicly release it.
One that subject, I would *love* to take the time to see how small a
subset of Ext2 I could write to have a (mostly) non-invasive source
code
podda wrote:
>
> i'm a linux newbie trying to learn kernel magic. i would be glad if
> someone can advice me where to look for to get an idea of the linux
> kernel. hey i don't need that one. ( "use the force, read the source" )
>
> i already tried to use the force , but can't figure out where i
Daniel Quinlan wrote:
> 4. If the robot likes the patch, it will create a unique identifier
>(i.e. "KP7562") and prepend a log entry to the body of the patch:
>
> --- linux/Documentation/patch-log Tue Aug 29 17:24:37 2000
> +++ linux/Documentation/patch-log Tue Aug 29 17:24:44
Jamie Lokier wrote:
>
> Michael Elizabeth Chastain wrote:
> > A source control system so that curious people could do the equivalent of
> > "cvs annotate" and figure out who wrote particular pieces?
>
> Note convinced about "cvs annotate". Maybe annotation with version
> numbers. But "cvs
Linus Torvalds wrote:
>
> It's not whether you can use tools to do the work.
>
> It's about what kind of people you get.
This makes a lot of sense. Stop there and you are done. But...
> ...in the end, maybe the rule to only use hand power makes sense. Not
> because hand-power is _better_. Bu
Simon Huggins wrote:
> On Thu, Sep 07, 2000 at 08:46:56AM +1100, Keith Owens wrote:
> ... and a few more times recent weeks ...
>
> >
> > Why don't you look in linux/Documentation/Changes? That file exist
> > precisely to stop repeated questions like this on the linux kernel
> > developers list
Christer Weinigel wrote:
>
> [[EMAIL PROTECTED]] wrote:
>
> >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 th
Gregory Maxwell wrote:
>
> On Wed, 6 Sep 2000, Alan Cox wrote:
>
> > > Ehh? And exactly _how_ would a debugger help it.
> > >
> > > Especially as Alan quoted an example of a driver bug that didn't get fixed
> > > for several months because the maintainer didn't have the hardware.
> > >
> > > Wha
Linus Torvalds wrote:
>
> And quite frankly, for most of the real problems (as opposed to the stupid
> bugs - of which there are many, as the latest crap with "truncate()" has
> shown us) a debugger doesn't much help. And the real problems are what I
> worry about. The rest is just details. It wil
Mike Galbraith wrote:
>
> On Wed, 6 Sep 2000, Damien Miller wrote:
>
> > Tools like a KDB would make the kernel a lot more accessible to the
> > time-poor.
>
> Kdb is available to all. I think it should be _integrated_ mostly
> because of the (potential) improvement in bug report quality.
Wel
Mike Jagdis wrote:
> I disagree. No one here is dumb enough to use a wholely inappropriate
> tool for a particular task. But using a debugger is often (but not
> always) like sawing bits off your 2x4 until it happens to fit the
> gap. What you need to do is to understand the problem parameters,
>
"David S. Miller" wrote:
>
> From: Chris Wedgwood <[EMAIL PROTECTED]>
>
>Right now as I see it (pretending everything is black and white);
>you, Dave, Linus and a few other people[1] are more than happy with
>debugging aids as they exist right now in a stock kernel.
>
>However,
Alexander Viro wrote:
>
> "Make it easy" is OK, unless it is followed by "for lusers". And anyone
> saying that code reviews are not practical can go and fuck himself. He
> will, anyway. Code reviews are MUST. I have no problems with folks who
> want to have debugger in addition to that. I consid
(reposted with non-mangled From address)
Alexander Viro wrote:
>
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
>
> > Rasmus, you introduced a bug because you removed the code but left the
> > comment around. now /* this should go into ->truncate */ is there and very
> > confusing - what should g
"David S. Miller" wrote:
> This is what a debugger does not do for you. The debugger allows you
> to be lazy, step around, "oh yeah check for NULL" and never have to
> _think_ about what you're doing or the changes you're making or even
> if the same bug might be elsewhere.
>
> This is why Linus
Alexander Viro wrote:
>
> On Fri, 1 Sep 2000, Tigran Aivazian wrote:
>
> > Rasmus, you introduced a bug because you removed the code but left the
> > comment around. now /* this should go into ->truncate */ is there and very
> > confusing - what should go into ->truncate?
>
> ... except that co
Arjan van de Ven wrote:
>
> In article <[EMAIL PROTECTED]> you
>wrote:
>
> > Well, the bug seems to exactly using the page after a "free_page()". Which
> > is always a bug, but at least should be easy to fix.
>
> > I've considered making "free_page()" a macro something like
>
> > __free
Alexander Viro wrote:
>
> On Fri, 1 Sep 2000, Daniel Phillips wrote:
>
> > Linda Walsh wrote:
> > > It may not matter too too much, but blocks are being passed around as
> > > 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T
Linda Walsh wrote:
> It may not matter too too much, but blocks are being passed around as
> 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T
> disk size. Probably don't need to worry about this today, but in a few
> years? Should we be changing the internal interfaces to
Alan Cox wrote:
>
> > > So cat it with a magic lead in after the bzImage gzip block into the bzImage.
> > > If you dont even know what file you are running for kernel you have other
> > > problems anyway
> >
> > Does also include the build number (i.e. the first part of
>
> Reread my suggestion
Nathan Paul Simons wrote:
> As for the argument of putting it in the kernel being more robust and
> idiot-proof, well, if someone can't keep three files and one directory
> straight for each different configuration of the kernel that they want to
> play with, they probably shouldn't be con
Alexander Viro wrote:
> On Wed, 30 Aug 2000, Roman Zippel wrote:
> > > What? You've proposed locking on pageout. If _that_ isn't the fast path...
> >
> > No, I suggested a lock (not necessarily the inode lock) during allocation
> > of indirect blocks (and defer truncation of them).
>
> Wh
Michael Peddemors wrote:
> The ./Documentation/i386/boot.txt written by HPA is a nice start about the
> boot processes, but yes, I found that very few people on this list have the
> time to explain generalized concepts. Makes it hard to wade in and
> contribute.. My struggles with INITRD_START
as the subject or body to:
[EMAIL PROTECTED]
--
Daniel Phillips
software engineer, innominate AG
[EMAIL PROTECTED]
http://innominate.de
-
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/
701 - 738 of 738 matches
Mail list logo
