blkmtd and name_to_dev_t

blkmtd and name_to_dev_t

[H. Peter Anvin]

Hello all,

I'm trying to revamp the Linux kernel by moving a lot of (mainly) 
initialization code to "early userspace" -- a tiny userspace carried 
with the kernel image.  This is sometimes referred to as the "klibc" 
project.

I sent a git tree to Andrew Morton for possible integration in -mm, and 
it got rejected due to the fact that the blkmtd driver uses 
name_to_dev_t() when compiled into the kernel, which is removed in the 
klibc tree -- it is now strictly a matter of userspace policy.

I talked to Jörg Engel about this; he indicated that the blkmtd driver 
(which is the one that has this problem) is already deprecated in favour 
of block2mtd.  Hence I'm hesitant to spend a lot of time on this, 
especially in the light of the fact that keeping a 90,000-line patch up 
to date with an evolving kernel is a challenge in itself.

There seems to be a few options, in order from least work to more work:

- Removing the blkmtd driver and tell people to use block2mtd;
- Have kinit intercept blkmtd configuration options and emulate them 
using block2mtd;
- Adjust blkmtd to have a configuration interface, and then make kinit 
configure it.

I would appreciate any opinions on this.  Clearly, I'm eager at getting 
unblocked on this, but my submitting a tree to Andrew which disables a 
driver without the maintainers' OK isn't exactly going to fly :)

For what it's worth, the klibc tree is at:

git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc.git

	-=hpa

Re: blkmtd and name_to_dev_t

[Jörn Engel]

On Thu, 30 March 2006 15:36:24 -0800, H. Peter Anvin wrote:
> 
> I talked to Jörg Engel about this; he indicated that the blkmtd driver 
                 ^
*grumble* ;)

> There seems to be a few options, in order from least work to more work:
> 
> - Removing the blkmtd driver and tell people to use block2mtd;

Fair enough.  No objections from my side.
Most users of mtd tend to use ancient kernels anyway, so there is less
reason for a warning period, compared to other parts of the kernel.

> - Have kinit intercept blkmtd configuration options and emulate them 
> using block2mtd;
> - Adjust blkmtd to have a configuration interface, and then make kinit 
> configure it.

Jörn

-- 
I don't understand it. Nobody does.
-- Richard P. Feynman

Re: blkmtd and name_to_dev_t

[H. Peter Anvin]

Jörn Engel wrote:
> On Thu, 30 March 2006 15:36:24 -0800, H. Peter Anvin wrote:
>> I talked to Jörg Engel about this; he indicated that the blkmtd driver 
>                  ^
> *grumble* ;)
> 

*D'OH!!!*  SORRY!!!!! :) :) :)

	-hpa

Re: blkmtd and name_to_dev_t

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> There seems to be a few options, in order from least work to more work:
>
> - Removing the blkmtd driver and tell people to use block2mtd;
> - Have kinit intercept blkmtd configuration options and emulate them using
> block2mtd;
> - Adjust blkmtd to have a configuration interface, and then make kinit configure
> it.

Block devices are not especially interesting when working with flash chips, as they
are an emulation layer.  The character devices are much more interesting,
and the native filesystems don't go through a block or a character device.
So killing blkmtd sounds like a reasonable thing to do.

Given that klibc will reduce the size of the kernel I expect most embedded
users will in general be in favor of it.

So I suggest what happens is that we deprecate blkmtd in Documentation/FeatureRemoval
of 2.6.17 and delete it in the -mm tree.

Then you can merge klibc.

Does any one have a problem with that plan?

Eric

Re: blkmtd and name_to_dev_t

[H. Peter Anvin]

Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>> There seems to be a few options, in order from least work to more work:
>>
>> - Removing the blkmtd driver and tell people to use block2mtd;
>> - Have kinit intercept blkmtd configuration options and emulate them using
>> block2mtd;
>> - Adjust blkmtd to have a configuration interface, and then make kinit configure
>> it.
> 
> Block devices are not especially interesting when working with flash chips, as they
> are an emulation layer.  The character devices are much more interesting,
> and the native filesystems don't go through a block or a character device.
> So killing blkmtd sounds like a reasonable thing to do.
> 

I thought (am I wrong?) that blkmtd referred to using a block device as 
an MTD device.  Either which way, Jörn tells me that blkmtd is 
deprecated by block2mtd anyway, and only retained for boot support, 
which is pretty easy to do in klibc.

> Given that klibc will reduce the size of the kernel I expect most embedded
> users will in general be in favor of it.
> 
> So I suggest what happens is that we deprecate blkmtd in Documentation/FeatureRemoval
> of 2.6.17 and delete it in the -mm tree.
> 
> Then you can merge klibc.
> 
> Does any one have a problem with that plan?

That certainly works for me.  Jörn indicated he's going to sign off on a 
patch to remove blkmtd, which will solve my problem.

	-hpa

Re: blkmtd and name_to_dev_t

[Jörn Engel]

On Mon, 3 April 2006 20:07:48 -0700, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> 
> I thought (am I wrong?) that blkmtd referred to using a block device as 
> an MTD device.  Either which way, Jörn tells me that blkmtd is 
> deprecated by block2mtd anyway, and only retained for boot support, 
> which is pretty easy to do in klibc.

You are not wrong.

A possibly better way to deliver the same functionality (jffs2 rootfs
on block device through emulation) might be to add transparent
translation support to jffs2.  Something that will make "mount
/dev/hda1 /mnt -t jffs2" work.  How exactly the code for this should
look, I don't know yet.  But given that jffs2 is the only sane user of
bd->mtd translation, it looks like the Right Thing to me.

> >So I suggest what happens is that we deprecate blkmtd in 
> >Documentation/FeatureRemoval
> >of 2.6.17 and delete it in the -mm tree.
> >
> >Then you can merge klibc.
> >
> >Does any one have a problem with that plan?
> 
> That certainly works for me.  Jörn indicated he's going to sign off on a 
> patch to remove blkmtd, which will solve my problem.

Once the coffee kicks in, yes.  Good morning everyone.

Ordinarily, we should go through the usual 1 year deprecation period
for blkmtd.  But in this case I find it justified to pull the support
immediatly:
o An alternative exists that hasn't had  bug report for > 1 year.
o Most embedded people tend to use ancient kernels with custom patches
  from mtd cvs and elsewhere, so the 1 year warning period neither
  helps nor hurts them too much.
o It's in the way of klibc.  The problems caused by pulling blkmtd
  support are fairly low, while the problems caused by delaying klibc
  can be fairly substantial.  At best, this would be a severe burden
  on hpa's time.

That said, deprecating the driver in -linus and removing it in -mm
until klibc is merged to -linus sounds like a good idea.  Will do
that.

Jörn

-- 
Anything that can go wrong, will.
-- Finagle's Law

Re: blkmtd and name_to_dev_t

[Artem B. Bityutskiy]

Jörn Engel wrote:
  > You are not wrong.
> 
> A possibly better way to deliver the same functionality (jffs2 rootfs
> on block device through emulation) might be to add transparent
> translation support to jffs2.  Something that will make "mount
> /dev/hda1 /mnt -t jffs2" work.  How exactly the code for this should
> look, I don't know yet.  But given that jffs2 is the only sane user of
> bd->mtd translation, it looks like the Right Thing to me.

This is a bit out of context and I'm not arguing. Just wanted to note. 
Mount and linux long support device-less mount. The beset way to mount 
JFFS2 would be to do like this:

mount mtd0 /mnt/jffs2 -t jffs2

No need to have any fake block device, no need to have any device node 
at all. JFFS2 seems to (not sure) not support this but it is trivial to add.

I tend to think that this mtdblock fake stuff is some ancient crap and 
has to go and not confuse people.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

Re: blkmtd and name_to_dev_t

[Jörn Engel]

On Tue, 4 April 2006 12:42:54 +0400, Artem B. Bityutskiy wrote:
> 
> This is a bit out of context and I'm not arguing. Just wanted to note. 
> Mount and linux long support device-less mount. The beset way to mount 
> JFFS2 would be to do like this:
> 
> mount mtd0 /mnt/jffs2 -t jffs2
> 
> No need to have any fake block device, no need to have any device node 
> at all. JFFS2 seems to (not sure) not support this but it is trivial to add.
> 
> I tend to think that this mtdblock fake stuff is some ancient crap and 
> has to go and not confuse people.

Artem, this is the other way around.  You are talking about having a
fake block device to mount jffs2 on mtd.  mtd->bd

I was talking about having a fake mtd on top of a block device to
mount jffs2 on it.  bd->mtd

Yes, the whole translate this into that business around mtd is rather
confusing.  It is unfortunate that a struct block_device is not
sufficient for flash purposes (yet?).

Jörn

-- 
Sometimes, asking the right question is already the answer.
-- Unknown

Re: blkmtd and name_to_dev_t

[Artem B. Bityutskiy]

Jörn Engel wrote:
> Artem, this is the other way around.  You are talking about having a
> fake block device to mount jffs2 on mtd.  mtd->bd
Yes yes. I said "This is a bit out of context and I'm not arguing".
I just noticed that the whole confusion came form these "mtdblock" 
devices... Sorry if I'm wrong.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

Re: blkmtd and name_to_dev_t

[Josh Boyer]

On 4/3/06, Eric W. Biederman <ebiederman@lnxi.com> wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > There seems to be a few options, in order from least work to more work:
> >
> > - Removing the blkmtd driver and tell people to use block2mtd;
> > - Have kinit intercept blkmtd configuration options and emulate them using
> > block2mtd;
> > - Adjust blkmtd to have a configuration interface, and then make kinit configure
> > it.
>
> Block devices are not especially interesting when working with flash chips, as they
> are an emulation layer.  The character devices are much more interesting,
> and the native filesystems don't go through a block or a character device.
> So killing blkmtd sounds like a reasonable thing to do.

Erm, you've got the idea behind blkmtd a bit backwards.  It's not to
make an MTD device show up as a block device.  It's to make a block
device show up as an MTD device.  Quite useful for testing JFFS2, etc
when one doesn't have immediate access to flash chips.  But that is
all beside the point.

> So I suggest what happens is that we deprecate blkmtd in Documentation/FeatureRemoval
> of 2.6.17 and delete it in the -mm tree.
>
> Then you can merge klibc.
>
> Does any one have a problem with that plan?

I believe this sounds good.

josh