Re: [Fwd: "Enhanced" MD code avaible for review]

Re: [Fwd: "Enhanced" MD code avaible for review]

[Christoph Hellwig]

On Wed, Mar 17, 2004 at 01:33:12PM -0500, Jeff Garzik wrote:
> A patch to fs/partitions/check.c is also required for this
> release to function correctly:
> 
> 	
> http://people.freebsd.org/~gibbs/linux/SRC/md_announce_whole_device.diff

Vetoed.  Kernel-level autodetection code is deprecated already, don't
even try to add functionality for it.

As for the actual code please post diffs instead of tarballs.

Re: [Fwd: "Enhanced" MD code avaible for review]

[Justin T. Gibbs]

> On Wed, Mar 17, 2004 at 01:33:12PM -0500, Jeff Garzik wrote:
>> A patch to fs/partitions/check.c is also required for this
>> release to function correctly:

Hmm.  I don't think Jeff wrote that.

>> http://people.freebsd.org/~gibbs/linux/SRC/md_announce_whole_device.diff
> 
> Vetoed.  Kernel-level autodetection code is deprecated already, don't
> even try to add functionality for it.

So do you speak for the entire community in expressing that auto-detection
will never make sense in the kernel?  Are you completely unwilling to
entertain even a minor discussion on the topic for those of us that don't
understand the concerns the community has in supporting it?

> As for the actual code please post diffs instead of tarballs.

If you look at the posted code, you'll see that diffs make little
sense at this point.  But I will generate diffs in addition
to the tarball with the next release later this week.

--
Justin

Re: [Fwd: "Enhanced" MD code avaible for review]

[Christoph Hellwig]

On Wed, Mar 17, 2004 at 11:54:05AM -0700, Justin T. Gibbs wrote:
> > On Wed, Mar 17, 2004 at 01:33:12PM -0500, Jeff Garzik wrote:
> >> A patch to fs/partitions/check.c is also required for this
> >> release to function correctly:
> 
> Hmm.  I don't think Jeff wrote that.

That's why it's doubly-quoted, right?

> >> http://people.freebsd.org/~gibbs/linux/SRC/md_announce_whole_device.diff
> > 
> > Vetoed.  Kernel-level autodetection code is deprecated already, don't
> > even try to add functionality for it.
> 
> So do you speak for the entire community in expressing that auto-detection
> will never make sense in the kernel?  Are you completely unwilling to
> entertain even a minor discussion on the topic for those of us that don't
> understand the concerns the community has in supporting it?

I speak about the concencus the 'community' has reached in the past.
If you invested the tiniest amount of googling you'd have seen messages
from Neil where he sais he'd rather get rid of autodetection ioctls
in favour of mdadm doing the work, and patches extending autodetection
beeing rejected.  Which pretty much fits into the general do it in
userspace if you can rule.

> > As for the actual code please post diffs instead of tarballs.
> 
> If you look at the posted code, you'll see that diffs make little
> sense at this point.  But I will generate diffs in addition
> to the tarball with the next release later this week.

Diffs alwasy make sense if you touch existing code.

Re: [Fwd: "Enhanced" MD code avaible for review]

[Justin T. Gibbs]

> On Wed, Mar 17, 2004 at 11:54:05AM -0700, Justin T. Gibbs wrote:
>> > On Wed, Mar 17, 2004 at 01:33:12PM -0500, Jeff Garzik wrote:
>> >> A patch to fs/partitions/check.c is also required for this
>> >> release to function correctly:
>> 
>> Hmm.  I don't think Jeff wrote that.
> 
> That's why it's doubly-quoted, right?

Hmm.  I didn't realize that Jeff was ever part of this thread.
I authored the text that you quoted and was just surprised to see
Jeff's name near it.  Never mind.

>> So do you speak for the entire community in expressing that auto-detection
>> will never make sense in the kernel?  Are you completely unwilling to
>> entertain even a minor discussion on the topic for those of us that don't
>> understand the concerns the community has in supporting it?
> 
> I speak about the concencus the 'community' has reached in the past.
> If you invested the tiniest amount of googling you'd have seen messages
> from Neil where he sais he'd rather get rid of autodetection ioctls
> in favour of mdadm doing the work, and patches extending autodetection
> beeing rejected.  Which pretty much fits into the general do it in
> userspace if you can rule.

I'm aware of Neil's past comments on the subject, but I was not aware
of a more full discussion on what this means in terms of lost functionality
for Linux.  I would like to have that discussion.  I'm more than willing
to adjust our strategy once that discussion takes place and a consensus
is reached.

--
Justin

Re: [Fwd: "Enhanced" MD code avaible for review]

[Christoph Hellwig]

On Wed, Mar 17, 2004 at 12:05:51PM -0700, Justin T. Gibbs wrote:
> Hmm.  I didn't realize that Jeff was ever part of this thread.
> I authored the text that you quoted and was just surprised to see
> Jeff's name near it.  Never mind.

he forwarded the mail to me, and I didn't remove his name from the
mutt inserted when replying, not intentional, but with the double
quotes it shouldn't be that confusing either..

> I'm aware of Neil's past comments on the subject, but I was not aware
> of a more full discussion on what this means in terms of lost functionality
> for Linux.  I would like to have that discussion.  I'm more than willing
> to adjust our strategy once that discussion takes place and a consensus
> is reached.

We're not far enough to actually removing functionlly yet.  For that
early userspace needs to get a little more mature and more widely used.

We're not going to add more functionaly like that. though.

Re: [Fwd: "Enhanced" MD code avaible for review]

[Hendrik Visage]

On Wed, Mar 17, 2004 at 08:01:17PM +0100, Christoph Hellwig wrote:
> > >> http://people.freebsd.org/~gibbs/linux/SRC/md_announce_whole_device.diff
> > > 
> > > Vetoed.  Kernel-level autodetection code is deprecated already, don't
> > > even try to add functionality for it.
> > 
> > So do you speak for the entire community in expressing that auto-detection
> > will never make sense in the kernel?  Are you completely unwilling to
> > entertain even a minor discussion on the topic for those of us that don't
> > understand the concerns the community has in supporting it?

I personally see the use for it, but alas. This have also been an
for EVMS and the reason they`ve changed so radically change between 1.2 and 2.0
 
> I speak about the concencus the 'community' has reached in the past.
> If you invested the tiniest amount of googling you'd have seen messages
> from Neil where he sais he'd rather get rid of autodetection ioctls
> in favour of mdadm doing the work, and patches extending autodetection
> beeing rejected.  Which pretty much fits into the general do it in
> userspace if you can rule.

Yes.
Personally I have different views on it, but that's the direction that especially the hardcore kernel developers on the linux kernel mailing list views the
world and auto discovery etc.

Hendrik

Re: [Fwd: "Enhanced" MD code avaible for review]

[Jeff Garzik]

(added linux-kernel to CC, where IMO the discussion on wider issues belongs)

Christoph Hellwig wrote:
> On Wed, Mar 17, 2004 at 12:05:51PM -0700, Justin T. Gibbs wrote:
>>I'm aware of Neil's past comments on the subject, but I was not aware
>>of a more full discussion on what this means in terms of lost functionality
>>for Linux.  I would like to have that discussion.  I'm more than willing
>>to adjust our strategy once that discussion takes place and a consensus
>>is reached.
> 
> 
> We're not far enough to actually removing functionlly yet.  For that
> early userspace needs to get a little more mature and more widely used.
> 
> We're not going to add more functionaly like that. though.

If early userspace isn't ready, it sounds like a choice between 
"nothing" and "it works".

We want a clean, tasteful solution, sure.  But I think we can work 
within the confines of the existing 2.6 API, and not postpone this stuff 
under early userspace is ready.

<rant>
Overall... the storage industry finally got off their ass and created a 
vendor-neutral RAID format, and they're actually using it.  Linux users 
don't deserve to be left out in the cold until 2.7.x klibc stuff is in, 
since they will be buying such RAID hardware right now.

I got into the Linux kernel game years ago in a large part because of 
precisely this -- getting Linux users going on hardware that would 
otherwise be Windows-only, without my help.  (or would otherwise be a 
grotty and buggy vendor driver, without my help:))
</rant>

	Jeff

Re: [Fwd: "Enhanced" MD code avaible for review]

[Christoph Hellwig]

On Wed, Mar 17, 2004 at 02:28:59PM -0500, Jeff Garzik wrote:
> If early userspace isn't ready, it sounds like a choice between 
> "nothing" and "it works".
> 
> We want a clean, tasteful solution, sure.  But I think we can work 
> within the confines of the existing 2.6 API, and not postpone this stuff 
> under early userspace is ready.

Umm, early userspace works nicely, you don't need the klibc and
initramfs buzzwords for that, good 'ol initrd still works and people
actually use it, e.g. for dm.

Re: [Fwd: "Enhanced" MD code avaible for review]

[Jeff Garzik]

Christoph Hellwig wrote:
> On Wed, Mar 17, 2004 at 02:28:59PM -0500, Jeff Garzik wrote:
> 
>>If early userspace isn't ready, it sounds like a choice between 
>>"nothing" and "it works".
>>
>>We want a clean, tasteful solution, sure.  But I think we can work 
>>within the confines of the existing 2.6 API, and not postpone this stuff 
>>under early userspace is ready.
> 
> 
> Umm, early userspace works nicely, you don't need the klibc and
> initramfs buzzwords for that, good 'ol initrd still works and people
> actually use it, e.g. for dm.

Agreed.  initrd works in 2.4, too...

	Jeff