linux-kernel - Re: Boot failure with ext2 and initrds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20061129181602.GD23101@flint.arm.linux.org.uk>
Date:	Wed, 29 Nov 2006 18:16:02 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Andrew Morton <akpm@...l.org>
Cc:	Mingming Cao <cmm@...ibm.com>, Hugh Dickins <hugh@...itas.com>,
	Mel Gorman <mel@...net.ie>,
	"Martin J. Bligh" <mbligh@...igh.org>,
	linux-kernel@...r.kernel.org,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Boot failure with ext2 and initrds

On Wed, Nov 29, 2006 at 01:39:22AM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 09:20:24 +0000
> Russell King <rmk+lkml@....linux.org.uk> wrote:
> 
> > What I'm looking for is confirmation of the semantics of
> > find_next_zero_bit()
> 
> What are the existing semantics?  I see no documentation in any of the
> architectures I've looked at.  That's my point.
> 
> >From a quick read of fs/ext2/balloc.c
> 
> 	ext2_find_next_zero_bit(base, size, offset)
> 
> appears to expect that base is the start of the memory buffer, size is the
> number of bits at *base and offset is the bit at which to start the search,
> relative to base.  If a zero bit is found it will return the offset of that
> bit relative to base.  It will return some number greater than `size' if no
> zero-bit was found.  

Thank you for taking the time to agree with my analysis of x86 and
confirm that what ARM implements is also what is expected - that's
all that I was after.  The reason I was after it was because you'd
said in the message I originally replied to:

| yes, the `size' arg to find_next_zero_bit() represents the number of
| bits to scan at `offset'.

which is entirely different from my understanding of what is required of
this function.  Hence the confusion caused and the need to clear up
that confusion.

> Whether that's how all the implementors interpreted it is anyone's guess. 
> Presumably the architectures all do roughly the same thing.

ARM does exactly the same as x86, since x86 was the only architecture
which existed in Linux when it was originally implemented.

> > <extremely frustrated>
> 
> Well likewise.  It appears that nobody (and about 20 people have
> implemented these things) could be bothered getting off ass and
> documenting the pathetic thing.

Back in those days it very much was "read the source, luke" and when
porting the kernel that meant the x86 code.  Consider the lack of
documentation a case of just following the agreed convention at the
time.

We've since now moved on to a more mature attitude towards documentation,
and decided upon a format that it should take.  So yes, it would be nice
if someone would document the entire set of kernel functions which
architectures are expected to provide.  That'll probably be a full time
job for someone though, and probably needs someone to be paid to do it.
Or are the janitor folks up for it?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/