Congrats Marcelo,

Congrats Marcelo,

[Dennis, Jim]

Marcelo,

 Contratulations on your first "official" kernel release.  It seems to have
gone
 well (except for some complaints on slashdot about -rc4 SPARC patches
missing from
 the patch, but apparently in the full tarball).

 Now I need to know about the status of several unofficial patches:

	XFS
	LVM
	i2c
	Crypto
	FreeS/WAN KLIPS
	LIDS
	rmap


 Shawn was very helpful regarding the XFS+rmap patches --- though I've been
having 
 some trouble with compiling kernels out of that in some configurations
(I'll try to 
 isolate those and submit a coherent bug report, if I can.  Shawn, are you
going to 
 update your set of XFS+rmap patches soon?

 Marcelo, there were some i2c updates included in the lmsensors package,
have they
 submitted those to you for integration into 2.4.19?

(As for the patch-int, that seems to apply with only a couple minor rejects,
to the
 top level Makefile, and Documentation/Configure.help; so that's not a
problem --- 
 beside I want KLIPS, LIDS and patch-int for home, not for work.)

 

Re: Congrats Marcelo,

[H. Peter Anvin]

Followup to:  <2D0AFEFEE711D611923E009027D39F2B153AD4@cdserv.meridian-data.com>
By author:    "Dennis, Jim" <jdennis@snapserver.com>
In newsgroup: linux.dev.kernel
> 
>  Contratulations on your first "official" kernel release.
> 

Third, actually.  2.4.16 .17 .18 were all Marcelo.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Congrats Marcelo,

[Andreas Dilger]

On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
>  Now I need to know about the status of several unofficial patches:

While my word is by no means official, my general understanding is:

> 	XFS

Not for 2.4 - just too many changes to the core kernel code.

> 	LVM

Heinz already submitted updates for LVM.

> 	i2c
> 	Crypto
> 	FreeS/WAN KLIPS
> 	LIDS

No idea.

> 	rmap

I don't think Rik has even asked for this to be included yet, as he
still has some known issues to be worked out.

In any case, Marcelo (probably) isn't out hunting for new patches to
add (especially after Alan's email about 78 patches he sent yesterday).
If the maintainers feel their code is ready and ask Marcelo to include
it, you will probably read about it here first.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

crypto (was Re: Congrats Marcelo,)

[Jeff Garzik]

Andreas Dilger wrote:
> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
> >  Now I need to know about the status of several unofficial patches:

> >       i2c
> >       Crypto
> >       FreeS/WAN KLIPS
> >       LIDS
> 
> No idea.

I would -love- to see crypto in the mainstream kernel.  Distribution of
crypto software on kernel.org has been OK for a while now.

Who knows what the kerneli guys, freeswan, etc. guys think.

IMO it's time to get a good IPsec implementation in the kernel...

	Jeff




-- 
Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Re: crypto (was Re: Congrats Marcelo,)

[Robert Love]

On Tue, 2002-02-26 at 16:15, Jeff Garzik wrote:

> I would -love- to see crypto in the mainstream kernel.  Distribution of
> crypto software on kernel.org has been OK for a while now.
> 
> Who knows what the kerneli guys, freeswan, etc. guys think.
> 
> IMO it's time to get a good IPsec implementation in the kernel...

Besides IPsec, what crypto is there for the kernel?  I've never really
understood what "crypto in the kernel means" since it all should be a
userspace thing.

Except IPsec, of course, and adding Freeswan would be a Good Thing. 
Freeswan people?

One thing I've heard in the past is "Yes, the US is safe now wrt
encryption but <country> is not" -- and I've seen country=France,etc
i.e. (self) important places.

	Robert Love

Re: crypto (was Re: Congrats Marcelo,)

[arjan]

In article <1014759355.1109.31.camel@phantasy> you wrote:
> Besides IPsec, what crypto is there for the kernel?  I've never really
> understood what "crypto in the kernel means" since it all should be a
> userspace thing.

loopback mount crypto. you want the actual crypts in kernel to avoid 2
context switches per block you read.

Re: crypto (was Re: Congrats Marcelo,)

[Robert Love]

On Tue, 2002-02-26 at 16:40, arjan@fenrus.demon.nl wrote:

> loopback mount crypto. you want the actual crypts in kernel to avoid 2
> context switches per block you read.

Oh, yes, indeed -- encrypted filesystems.  Then the issue is resolving
the various international concerns.

	Robert Love

Re: crypto (was Re: Congrats Marcelo,)

[Daniel Phillips]

On February 26, 2002 10:47 pm, Robert Love wrote:
> On Tue, 2002-02-26 at 16:40, arjan@fenrus.demon.nl wrote:
> 
> > loopback mount crypto. you want the actual crypts in kernel to avoid 2
> > context switches per block you read.
> 
> Oh, yes, indeed -- encrypted filesystems.  Then the issue is resolving
> the various international concerns.

I'd say, just put it in and let them resolve themselves.  If that bothers
China for example they can make their own censo^H^H^H^H^H edited tree,
they have their own homegrown Linux distribution.  I think they'll just
let it go.  Really, Linux is not going to get banned from any undemocratic
countries, it's too useful.

The governments of democratic countries such as France will not object, or
if they do then they will end up being severely larted by their own
citizens, that's a fight they can't possibly win.

/me thinks about the jolly fuss that would ensue if France censored Linux

-- 
Daniel

Re: crypto (was Re: Congrats Marcelo,)

[Bill Davidsen]

On Mon, 25 Feb 2002, Daniel Phillips wrote:

> /me thinks about the jolly fuss that would ensue if France censored Linux

Given that France blocks Ebay and there are a lot more people using that,
I don't think they would hesitate a moment. Don't get me started on this
topic...

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: crypto (was Re: Congrats Marcelo,)

[Francois Romieu]

Bill Davidsen <davidsen@tmr.com> :
[...]
> Given that France blocks Ebay and there are a lot more people using that,
> I don't think they would hesitate a moment. Don't get me started on this
> topic...

I'll fill the papers this WE and see what happens. It will take some 
(bounded) time of processing.

-- 
Ueimor

Re: crypto (was Re: Congrats Marcelo,)

[Francois Romieu]

Robert Love <rml@tech9.net> :
[...]
> One thing I've heard in the past is "Yes, the US is safe now wrt
> encryption but <country> is not" -- and I've seen country=France,etc
> i.e. (self) important places.

The first crypto-distributing site in France will have to fill some
papers and wait a fixed amount of time to know whether is request is
dismissed (I already filled these once, it doesn't suck *that* much).
After that, the end-user won't experience any real problem. The question
boils down to "Are you a crypto provider or an end-user ?".

-- 
Ueimor - just waiting to see the proof-of-concept "crypto in 2.5" patch.

Re: crypto (was Re: Congrats Marcelo,)

[Rik van Riel]

On Tue, 26 Feb 2002, Jeff Garzik wrote:

> IMO it's time to get a good IPsec implementation in the kernel...

Where would we get one of those ?

The freeswan folks seem quite determined to not let any
americans touch their code, so inclusion of their stuff
into the kernel is out.

Do you know of a nice ipsec implementation we could use?

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: crypto (was Re: Congrats Marcelo,)

[Michael H. Warfield]

On Tue, Feb 26, 2002 at 07:33:50PM -0300, Rik van Riel wrote:
> On Tue, 26 Feb 2002, Jeff Garzik wrote:

> > IMO it's time to get a good IPsec implementation in the kernel...

> Where would we get one of those ?

> The freeswan folks seem quite determined to not let any
> americans touch their code, so inclusion of their stuff
> into the kernel is out.

	No...  That's patently not true.

	They won't accept contributions from us, but we touch
their code all the time.  If we didn't, how would we get any testing
done, which they do accept from us.

	Also, several of them have stated on several occasions (this is
the prerequisite religious war that pops up every few months) that
they have no say in what other people do with the code (subject to the
license of course) and that inclusion of klips in the mainline kernel
would be beyond their control, yeah or nay.  Klips is the ONLY part
of freeswan that would go in the kernel.  Pluto (IKE) is the user
space part.

	They won't accept contributions from US developers to their code
base.  That does NOT mean that they will not accept contributing the IPSec
kernel code to the kernel and the incorporation of klips into the kernel
source tree.

> Do you know of a nice ipsec implementation we could use?

	Yes.  FreeSWAN.  And the FreeSWAN developers have as much as said so.

> Rik
> -- 
> "Linux holds advantages over the single-vendor commercial OS"
>     -- Microsoft's "Competing with Linux" document
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: crypto (was Re: Congrats Marcelo,)

[Rik van Riel]

On Wed, 27 Feb 2002, Michael H. Warfield wrote:
> On Tue, Feb 26, 2002 at 07:33:50PM -0300, Rik van Riel wrote:
> > On Tue, 26 Feb 2002, Jeff Garzik wrote:
>
> > > IMO it's time to get a good IPsec implementation in the kernel...
>
> > Where would we get one of those ?
>
> > The freeswan folks seem quite determined to not let any
> > americans touch their code, so inclusion of their stuff
> > into the kernel is out.
>
> 	No...  That's patently not true.
>
> 	They won't accept contributions from us, but we touch
> their code all the time.  If we didn't, how would we get any testing
> done, which they do accept from us.

> 	They won't accept contributions from US developers to their code
> base.  That does NOT mean that they will not accept contributing the IPSec
> kernel code to the kernel and the incorporation of klips into the kernel
> source tree.

Wouldn't that result in the following scenario:

1) freeswan gets merged into the kernel

2) davem fixes a networking thing which
   happens to touch freeswan

3) the freeswan developers don't take davem's
   fix into their tree

4) the next patch by the freeswan people doesn't
   apply to what's in the kernel


Somehow this scenario doesn't seem like it would make
the ipsec implementation very maintainable.

Maybe it would be better to use what the usagi people
are building, just to have an easier maintainable system?

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: crypto (was Re: Congrats Marcelo,)

[Michael H. Warfield]

On Wed, Feb 27, 2002 at 06:57:24PM -0300, Rik van Riel wrote:
> On Wed, 27 Feb 2002, Michael H. Warfield wrote:
> > On Tue, Feb 26, 2002 at 07:33:50PM -0300, Rik van Riel wrote:
> > > On Tue, 26 Feb 2002, Jeff Garzik wrote:
> >
> > > > IMO it's time to get a good IPsec implementation in the kernel...
> >
> > > Where would we get one of those ?
> >
> > > The freeswan folks seem quite determined to not let any
> > > americans touch their code, so inclusion of their stuff
> > > into the kernel is out.
> >
> > 	No...  That's patently not true.
> >
> > 	They won't accept contributions from us, but we touch
> > their code all the time.  If we didn't, how would we get any testing
> > done, which they do accept from us.
> 
> > 	They won't accept contributions from US developers to their code
> > base.  That does NOT mean that they will not accept contributing the IPSec
> > kernel code to the kernel and the incorporation of klips into the kernel
> > source tree.
> 
> Wouldn't that result in the following scenario:

> 1) freeswan gets merged into the kernel

	No...  Klips gets integrated into the kernel.  Pluto and the
supporting code and utilities are user space.

> 2) davem fixes a networking thing which
>    happens to touch freeswan

	FreeSWAN consists of two pieces, klips (Kernel Level IPSec) and
pluto plus a lot of user space glue.  Let's keep them separated into
the klips portion and the non-klips portion to cut down on the
confusion here.

	Dave, fixing a network thing, would only touch klips or one of
the interfaces.  He doesn't "touch" the non-klips code at all.  If there
is a user-space interface change, it's up to the FreeSWAN gang to
"touch" the user space code in the scripts and in pluto.  Dave doesn't
touch the user space stuff.

> 3) the freeswan developers don't take davem's
>    fix into their tree

	Once klips is in the kernel tree, it's no longer in their tree
other than code for legacy versions which lack integrated klips.
Changes or fixes to klips get submitted to the kernel sources for
the integrated versions and they become maintainers for that portion
of the kernel tree.  Their contribtutions come this way into the klips
sources in the kernel tree, not the other way around.

> 4) the next patch by the freeswan people doesn't
>    apply to what's in the kernel

	The subject on the FreeSWAN list has been targeted at getting
the klips code out of FreeSWAN and into the kernel so the only changes
or patches they make are changes against the code in the kernel outside
of the legacy kernel versions.

	Last I understood them to say, they agree that they have no
control over the incorporation of klips into the kernel and they
seem to have no problem contributing code which is used by and integrated
into software by US developers.  They just can't accept code FROM
US developers.  That implies that once klips, and only klips, is
integrated into the kernel, both parties contribute changes to that
module while the FreeSWAN developers manage their user space utilities
and code while accepting no contributions from the US developers.

> Somehow this scenario doesn't seem like it would make
> the ipsec implementation very maintainable.

	It should actually make it MORE maintainable and more installable.
If klips is in the kernel then they don't have to worry about patching
the kernel just to install FreeSWAN.  Then they can take pluto and all
the associated support stuff and roll it into a user space application
package or and rpm that can simply be agregated with the distributions.
They are even moving in that direction now by separating the builds
so that the kernel level code and pluto no longer share libraries or
common sources.  That's enabled some people to build freeswan rpms
for the user space stuff now as long as the kernel gets patched
for klips.

	The one major downside, right now, is that Henry and Richard
et al, keep talking about redesigning the klips structure to fit
in with the more recent kernels better (ala netfilter, maybe).  They've
announced some design specs and I suspect that they would rather
see the newer version of klips in the kernel tree than the crufty
version that we are hobbled with in FreeSWAN right now.  Search the
FreeSWAN archives for discussions over routing and multiple tunnels
and the ipsec{n} interfaces to see what I meam about being hobbled
by the crufty klips interface.  Even they don't like the state
it's in.

> Maybe it would be better to use what the usagi people
> are building, just to have an easier maintainable system?

> regards,
> 
> Rik
> -- 
> "Linux holds advantages over the single-vendor commercial OS"
>     -- Microsoft's "Competing with Linux" document
> 
> http://www.surriel.com/		http://distro.conectiva.com/

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: crypto (was Re: Congrats Marcelo,)

[Rik van Riel]

On Wed, 27 Feb 2002, Michael H. Warfield wrote:

> 	The one major downside, right now, is that Henry and Richard
> et al, keep talking about redesigning the klips structure to fit
> in with the more recent kernels better (ala netfilter, maybe).

> FreeSWAN archives for discussions over routing and multiple tunnels
> and the ipsec{n} interfaces to see what I meam about being hobbled
> by the crufty klips interface.  Even they don't like the state
> it's in.

That's another issue with freeswan.  Nobody seems happy with
the current state of the code  ;)


regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Congrats Marcelo,

[Steve Lord]

On Tue, 2002-02-26 at 15:06, Andreas Dilger wrote:
> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
> >  Now I need to know about the status of several unofficial patches:
> 
> While my word is by no means official, my general understanding is:
> 
> > 	XFS
> 
> Not for 2.4 - just too many changes to the core kernel code.

Someone has got to kill this assumption people have about XFS, it
makes much smaller changes than some things which have gone in,
the odd VM rewrite here and there to name some. Given that we now
have official EA system calls, the last chunk of stuff to resolve
is quota. This is being worked on with Jan Kara.

Steve


-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com

Re: Congrats Marcelo,

[Daniel Phillips]

On February 26, 2002 10:56 pm, Steve Lord wrote:
> On Tue, 2002-02-26 at 15:06, Andreas Dilger wrote:
> > On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
> > >  Now I need to know about the status of several unofficial patches:
> > 
> > While my word is by no means official, my general understanding is:
> > 
> > > 	XFS
> > 
> > Not for 2.4 - just too many changes to the core kernel code.
> 
> Someone has got to kill this assumption people have about XFS, it
> makes much smaller changes than some things which have gone in,
> the odd VM rewrite here and there to name some. Given that we now
> have official EA system calls, the last chunk of stuff to resolve
> is quota. This is being worked on with Jan Kara.

I'd really like to see XFS go in, but don't you think 2.5 is the place,
with a view to 2.4 submission in due course?

As far as making the case goes, do you have time to make a list of
places where XFS goes outside fs/xfs, and why?

-- 
Daniel

Re: Congrats Marcelo,

[Steve Lord]

On Sun, 2002-02-24 at 17:39, Daniel Phillips wrote:
> 
> I'd really like to see XFS go in, but don't you think 2.5 is the place,
> with a view to 2.4 submission in due course?

This is my thinking, but the way 2.5 is diverging the argument that
xfs being stable in 2.5 prior to going into 2.4 probably will not mean
too much at the end of the day since the interfaces will probably
have diverged so much by then - and the interfaces are where the
nasties tend to come out. The core of XFS is pretty darn stable.

> 
> As far as making the case goes, do you have time to make a list of
> places where XFS goes outside fs/xfs, and why?

I have had about 20 emails since I got yours ;-) One of the reasons
I have not been attempting to submit XFS is that I have too many 
other things going on right now, hopefully things are getting 
quieter and I can take a shot at this again. I will see how tomorrow
goes ....

Steve

> 
> -- 
> Daniel
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com

Re: Congrats Marcelo,

[Daniel Phillips]

On February 27, 2002 12:07 am, Steve Lord wrote:
> On Sun, 2002-02-24 at 17:39, Daniel Phillips wrote:
> > I'd really like to see XFS go in, but don't you think 2.5 is the place,
> > with a view to 2.4 submission in due course?
> 
> This is my thinking, but the way 2.5 is diverging the argument that
> xfs being stable in 2.5 prior to going into 2.4 probably will not mean
> too much at the end of the day since the interfaces will probably
> have diverged so much by then - and the interfaces are where the
> nasties tend to come out. The core of XFS is pretty darn stable.

It will mean a lot.  It will mean Linus signed off on the integration,
and that the issues were examined.  Marcelo is perfectly capable of
determining what the additional 2.4 issues are, if any.

-- 
Daniel

Re: Congrats Marcelo,

[Rainer Ellinger]

Daniel Phillips wrote:

> I'd really like to see XFS go in, but don't you think 2.5 is the place,
> with a view to 2.4 submission in due course?

In my opinion the main problem behind the originating note is the big difference between the mainline "linus" kernel and what 
people really need or are really using. And this might be also a problem for development. Take distribution vendor kernels: make a 
diff of your favorite distribution kernel and the vanilla one and think about it. SuSE allows a detailed look inside at 
ftp://ftp.suse.com/pub/people/mantel/next/patches-2.4.18-0.tar.bz2

I think development in 2.5 should focus on including this waiting patches and come to a end and release asap. I think it's more 
important to catch up with real world needs and existing patches, than working on new developments.

> As far as making the case goes, do you have time to make a list of
> places where XFS goes outside fs/xfs, and why?

For me ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/README does it. ;-)

-- 
rainer@ellinger.de

Re: Congrats Marcelo,

[Daniel Phillips]

On February 27, 2002 12:23 am, Rainer Ellinger wrote:
> I think development in 2.5 should focus on including this waiting patches
> and come to a end and release asap. I think it's more important to catch up 
> with real world needs and existing patches, than working on new 
> developments.

They're both important.  If we focus only on features without evolving the 
underlying mechanisms we'll quickly end up with Windows.

Don't even think about asking Linus to stop working on new stuff.

-- 
Daniel

Re: Congrats Marcelo,

[Martin J. Bligh]

> I think development in 2.5 should focus on including this waiting 
> patches and come to a end and release asap. I think it's more 
> important to catch up with real world needs and existing patches, 
> than working on new developments.

More important for who ? ;-)

Linus and you (even the majority of the userbase) may not have
the same goals .... feel free to take what is in 2.5 right now,
stabilise it, and add these patches, making your own tree - you'd
probably make a lot of people happy.

Martin.

Re: Congrats Marcelo,

[Rainer Ellinger]

Martin J. Bligh wrote:
> the same goals .... feel free to take what is in 2.5 right now,
> stabilise it, and add these patches, making your own tree
 > probably make a lot of people happy.

That's the arrogant point of view, you can have, if you get paid for it. Please correct me, but I don't know any major tree from 
volunteers.

I have my own tree integrating XFS, LoopAES, UML, IPVS, Freeswan with X.509, LSM, TUX  and some smaller netfilter things. It's not 
a big deal integrating these patches, but it's still too much work. Guess, why i am not able to release this to public?

-- 
rainer@ellinger.de

Re: Congrats Marcelo,

[Martin J. Bligh]

>> the same goals .... feel free to take what is in 2.5 right now,
>> stabilise it, and add these patches, making your own tree
>  > probably make a lot of people happy.
> 
> That's the arrogant point of view, you can have, if you get 
> paid for it. Please correct me, but I don't know any major tree 
> from volunteers.

I was merely pointing out that his goals probably don't align
with yours, therefore it's a little pointless to tell him what he
should and shouldn't be concentrating on.

> I have my own tree integrating XFS, LoopAES, UML, IPVS, 
> Freeswan with X.509, LSM, TUX  and some smaller netfilter 
> things. It's not a big deal integrating these patches, but it's 
> still too much work. Guess, why i am not able to release this 
> to public?

I have no idea. My psychic powers seem to be fading of late.

M.

Re: Congrats Marcelo,

[Matthew D. Pitts]

Rainer,

I may be wrong, but I believe the Debian kernel tree is ENTIRELY volunteer
work. If that doesn't constitute a major tree, I don't know what does...

Matthew

----- Original Message -----
From: Rainer Ellinger <rainer@ellinger.de>
To: Martin J. Bligh <Martin.Bligh@us.ibm.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, February 26, 2002 7:47 PM
Subject: Re: Congrats Marcelo,


> Martin J. Bligh wrote:
> > the same goals .... feel free to take what is in 2.5 right now,
> > stabilise it, and add these patches, making your own tree
>  > probably make a lot of people happy.
>
> That's the arrogant point of view, you can have, if you get paid for it.
Please correct me, but I don't know any major tree from
> volunteers.
>
> I have my own tree integrating XFS, LoopAES, UML, IPVS, Freeswan with
X.509, LSM, TUX  and some smaller netfilter things. It's not
> a big deal integrating these patches, but it's still too much work. Guess,
why i am not able to release this to public?
>
> --
> rainer@ellinger.de
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Congrats Marcelo,

[Alan Cox]

> Someone has got to kill this assumption people have about XFS, it
> makes much smaller changes than some things which have gone in,
> the odd VM rewrite here and there to name some. Given that we now

Which was a complete disaster. IBM submitted Jfs into the -ac tree with
no lines of code changed outside fs/jfs. That is really the benchmark. 

Re: Congrats Marcelo,

[Steve Lord]

On Tue, 2002-02-26 at 16:59, Alan Cox wrote:
> > Someone has got to kill this assumption people have about XFS, it
> > makes much smaller changes than some things which have gone in,
> > the odd VM rewrite here and there to name some. Given that we now
> 
> Which was a complete disaster. IBM submitted Jfs into the -ac tree with
> no lines of code changed outside fs/jfs. That is really the benchmark.


Alan, I agree the VM changes had their issues, bad example, but LOTs of
things have gone into 2.4 which are more impactive than XFS, I just want
to get out of this image of XFS being the filesystem which ate the
kernel.

Yes jfs went in cleanly, because they reimplemented their filesystem
from the ground up, and had a large budget to do it. XFS does not fit
so cleanly because we brought along some features other filesystems did
not have:

  o Posix ACL support
  o The ability to do online filesystem dumps which are coherent with
    the system call interface
  o delayed allocation of file data
  o DMAPI

As it is we did all of these, and we seem to have half the Linux NAS
vendors in the world building xfs into their boxes.

Steve

-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com

Whither XFS? (was: Congrats Marcelo)

[Daniel Phillips]

On February 26, 2002 11:59 pm, Steve Lord wrote:
> Yes jfs went in cleanly, because they reimplemented their filesystem
> from the ground up, and had a large budget to do it. XFS does not fit
> so cleanly because we brought along some features other filesystems did
> not have:
> 
>   o Posix ACL support

Are you able to leverage the new EA interface?  (Which I still don't like
because of the namespace syntax embedded in the attribute names, btw,
please don't misinterpret silence as happiness.)

>   o The ability to do online filesystem dumps which are coherent with
>     the system call interface

It would be nice if some other filesystems could share that mechanism, do
you think it's feasible?  If not, what's the stumbling block?  I haven't
looked at this for some time and there's was some furious work going on
exactly there just before 2.5.  It seems we've at least progressed a
little from the viewpoint that nobody would want that.

>   o delayed allocation of file data

Andrew Morton is working on generic delayed allocation at the vfs level I
believe, why not bang heads with him and see if it can be made to work with
VFS?

>   o DMAPI

It would be nice to have unsucky file events.  But there's been roughly zero
discussion of dmapi on lkml as far as I can see.

> As it is we did all of these, and we seem to have half the Linux NAS
> vendors in the world building xfs into their boxes.

True enough.

-- 
Daniel

Re: Whither XFS? (was: Congrats Marcelo)

[Steve Lord]

On Sun, 2002-02-24 at 18:28, Daniel Phillips wrote:
> > 
> >   o Posix ACL support
> 
> Are you able to leverage the new EA interface?  (Which I still don't like
> because of the namespace syntax embedded in the attribute names, btw,
> please don't misinterpret silence as happiness.)

Where do you think the interface originated? A lot of time was spent
working on this and getting the ext2 and xfs code bases in sync.

> 
> >   o The ability to do online filesystem dumps which are coherent with
> >     the system call interface
> 
> It would be nice if some other filesystems could share that mechanism, do
> you think it's feasible?  If not, what's the stumbling block?  I haven't
> looked at this for some time and there's was some furious work going on
> exactly there just before 2.5.  It seems we've at least progressed a
> little from the viewpoint that nobody would want that.

Not really, there are some hooks into XFS which are probably totally
non-trivial for other filesystems.

> 
> >   o delayed allocation of file data
> 
> Andrew Morton is working on generic delayed allocation at the vfs level I
> believe, why not bang heads with him and see if it can be made to work with
> VFS?

Already talked at the end of last week, got majorly sidetracked again
this week. This is definitely something I would like to be able to
leverage for XFS. 

> 
> >   o DMAPI
> 
> It would be nice to have unsucky file events.  But there's been roughly zero
> discussion of dmapi on lkml as far as I can see.

Yep, and its not my strong suite. The previous attempt at an implementation
by someone else appears to have died a death.

> 
> > As it is we did all of these, and we seem to have half the Linux NAS
> > vendors in the world building xfs into their boxes.
> 
> True enough.

Now if only we could make some money out of them ;-)

Steve

> 
> -- 
> Daniel
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com

Re: Whither XFS? (was: Congrats Marcelo)

[Daniel Phillips]

On February 27, 2002 12:39 am, Steve Lord wrote:
> On Sun, 2002-02-24 at 18:28, Daniel Phillips wrote:
> > > 
> > >   o Posix ACL support
> > 
> > Are you able to leverage the new EA interface?...
> 
> Where do you think the interface originated? A lot of time was spent
> working on this and getting the ext2 and xfs code bases in sync.

Just checking.  So that's one place you're already syncing up with Linus.

> > 
> > >   o The ability to do online filesystem dumps which are coherent with
> > >     the system call interface
> > 
> > It would be nice if some other filesystems could share that mechanism, do
> > you think it's feasible?  If not, what's the stumbling block?  I haven't
> > looked at this for some time and there's was some furious work going on
> > exactly there just before 2.5.  It seems we've at least progressed a
> > little from the viewpoint that nobody would want that.
> 
> Not really, there are some hooks into XFS which are probably totally
> non-trivial for other filesystems.

So could you explain your approach here?  This pagebuf-land right?

> [...]
> > 
> > >   o DMAPI
> > 
> > It would be nice to have unsucky file events.  But there's been roughly zero
> > discussion of dmapi on lkml as far as I can see.
> 
> Yep, and its not my strong suite. The previous attempt at an implementation
> by someone else appears to have died a death.

I see Ben Lahaise aio proposal comes complete with a form of event queues,
would it be possible to share some of the machinery?

> > > As it is we did all of these, and we seem to have half the Linux NAS
> > > vendors in the world building xfs into their boxes.
> > 
> > True enough.
> 
> Now if only we could make some money out of them ;-)

Make money on XFS?  Not directly I'd say, but keeping customers happy when
they move to Linux - that has to count for something.  As far as making
heaps of $$$ goes, just keep shipping kickass boxes running real OS's and
don't get sucked in by billg again ;-)

-- 
Daniel

Re: Congrats Marcelo,

[J.A. Magallon]

On 20020226 Steve Lord wrote:
>On Tue, 2002-02-26 at 15:06, Andreas Dilger wrote:
>> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
>> >  Now I need to know about the status of several unofficial patches:
>> 
>> While my word is by no means official, my general understanding is:
>> 
>> > 	XFS
>> 
>> Not for 2.4 - just too many changes to the core kernel code.
>
>Someone has got to kill this assumption people have about XFS, it
>makes much smaller changes than some things which have gone in,
>the odd VM rewrite here and there to name some. Given that we now
>have official EA system calls, the last chunk of stuff to resolve
>is quota. This is being worked on with Jan Kara.
>

AFAIK, it does not so many changes but duplicates half the fs 
infrastructure already present in kernel just to have a common
codebase with IRIX.

Is this still true ?
Is anybody working in kill all the dups ?
 
-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-jam1 #1 SMP Tue Feb 26 00:06:55 CET 2002 i686

Re: Congrats Marcelo,

[Marcelo Tosatti]

On Tue, 26 Feb 2002, Dennis, Jim wrote:

> Marcelo,
> 
>  Contratulations on your first "official" kernel release.  It seems to
> have gone
>  well (except for some complaints on slashdot about -rc4 SPARC patches
> missing from
>  the patch, but apparently in the full tarball).
> 
>  Now I need to know about the status of several unofficial patches:
> 
> 	XFS

Want to see stable in -ac first.

> 	LVM

Its on 2.4 already.

> 	i2c
> 	Crypto
> 	FreeS/WAN KLIPS
> 	LIDS

I think its not possible to distribute crypto stuff in the stock kernel.

Am I wrong? 

> 	rmap

I need to see it running in production for more time.

>  Marcelo, there were some i2c updates included in the lmsensors package,
> have they
>  submitted those to you for integration into 2.4.19?

Nope. I could well integrate lm_sensors in the future.

Re: Congrats Marcelo,

[Alan Cox]

> > 	i2c
> > 	Crypto
> > 	FreeS/WAN KLIPS
> > 	LIDS
> 
> I think its not possible to distribute crypto stuff in the stock kernel.
> Am I wrong? 

It gets hairy. There are some jurisdictions where life is a lot easier
if its seperate. 

> > have they
> >  submitted those to you for integration into 2.4.19?
> 
> Nope. I could well integrate lm_sensors in the future.

Please be careful. lm_sensors can destroy machines if configured wrongly.
Thats something that needs tackling - and ironically ACPI may actually
solve that problem

Re: Congrats Marcelo,

[Dave Jones]

On Fri, 1 Mar 2002, Alan Cox wrote:

> > Nope. I could well integrate lm_sensors in the future.
> Please be careful. lm_sensors can destroy machines if configured wrongly.
> Thats something that needs tackling - and ironically ACPI may actually
> solve that problem

The machines in question are all IBMs iirc ? Could we work around
this with DMI strings for the suspect laptops ?

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Congrats Marcelo,

[Alan Cox]

> The machines in question are all IBMs iirc ? Could we work around
> this with DMI strings for the suspect laptops ?

DMI can help in a much more productive way. DMI tells you the type of 
sensor in the machine. Once you are using ACPI though you talk to ACPI
and it talks to the smbus etc and knows whats in the box

Re: Congrats Marcelo,

[Dave Jones]

On Fri, Mar 01, 2002 at 01:13:09AM +0000, Alan Cox wrote:
 > DMI can help in a much more productive way. DMI tells you the type of 
 > sensor in the machine. Once you are using ACPI though you talk to ACPI
 > and it talks to the smbus etc and knows whats in the box

 Given the fears of what happens when you look at i2c/smbus etc
 the wrong way, is this something we can rely on DMI tables
 to get right ?  When they can't get cachesize info right, I begin
 to question their ability to describe a temperature sensor.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Congrats Marcelo,

[Alan Cox]

>  > sensor in the machine. Once you are using ACPI though you talk to ACPI
>  > and it talks to the smbus etc and knows whats in the box
> 
>  Given the fears of what happens when you look at i2c/smbus etc
>  the wrong way, is this something we can rely on DMI tables
>  to get right ?  When they can't get cachesize info right, I begin
>  to question their ability to describe a temperature sensor.

The ones I looked at seemed credible - but yes it is an issue 8)

Re: Congrats Marcelo,

[Theodore Tso]

On Fri, Mar 01, 2002 at 12:01:51AM +0000, Alan Cox wrote:
> > 
> > Nope. I could well integrate lm_sensors in the future.
> 
> Please be careful. lm_sensors can destroy machines if configured wrongly.
> Thats something that needs tackling - and ironically ACPI may actually
> solve that problem

... as in instant death for any modern Thinkpad laptops, requiring a
trip back to the factory and a replacement of the motherboard...

*Please* don't integrate in lm_sensors without making sure the
thinkpad killing feature has been fixed.

						- Ted

Re: Congrats Marcelo,

[Mike Fedyk]

On Thu, Feb 28, 2002 at 08:28:03PM -0500, Theodore Tso wrote:
> On Fri, Mar 01, 2002 at 12:01:51AM +0000, Alan Cox wrote:
> > > 
> > > Nope. I could well integrate lm_sensors in the future.
> > 
> > Please be careful. lm_sensors can destroy machines if configured wrongly.
> > Thats something that needs tackling - and ironically ACPI may actually
> > solve that problem
> 
> ... as in instant death for any modern Thinkpad laptops, requiring a
> trip back to the factory and a replacement of the motherboard...
> 
> *Please* don't integrate in lm_sensors without making sure the
> thinkpad killing feature has been fixed.
>

Or, just don't integrate that part of the patch...

Re: Congrats Marcelo,

[Hans-Peter Jansen]

On Friday, 1. March 2002 02:53, Mike Fedyk wrote:
> On Thu, Feb 28, 2002 at 08:28:03PM -0500, Theodore Tso wrote:
> > On Fri, Mar 01, 2002 at 12:01:51AM +0000, Alan Cox wrote:
> > > > Nope. I could well integrate lm_sensors in the future.
> > >
> > > Please be careful. lm_sensors can destroy machines if configured
> > > wrongly. Thats something that needs tackling - and ironically ACPI may
> > > actually solve that problem
> >
> > ... as in instant death for any modern Thinkpad laptops, requiring a
> > trip back to the factory and a replacement of the motherboard...
> >
> > *Please* don't integrate in lm_sensors without making sure the
> > thinkpad killing feature has been fixed.
>
> Or, just don't integrate that part of the patch...

The problem is nested deeper, I suspect.
When accessing the detected sensor on my toshiba 8100,
the automatic temperature control isn't working any longer...
Normally you can hear it starting every time, the cpu is under 
load.

Better you reboot quickly after that, with lm-sensors (2.62) disabled
then...

Details on request.

Cheers,
  Hans-Peter

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Congrats Marcelo,

[Stephen Degler]

Hi,

FYI crypto is included in (Net|Free|Open)BSD source releases and I don't
believe it is an issue for them.

skd

On Thu, Feb 28, 2002 at 06:52:25PM -0300, Marcelo Tosatti wrote:
> 
> On Tue, 26 Feb 2002, Dennis, Jim wrote:
> 
> > Marcelo,
> > 
> >  Contratulations on your first "official" kernel release.  It seems to
> > have gone
> >  well (except for some complaints on slashdot about -rc4 SPARC patches
> > missing from
> >  the patch, but apparently in the full tarball).
> > 
> >  Now I need to know about the status of several unofficial patches:
> > 
> > 	XFS
> 
> Want to see stable in -ac first.
> 
> > 	LVM
> 
> Its on 2.4 already.
> 
> > 	i2c
> > 	Crypto
> > 	FreeS/WAN KLIPS
> > 	LIDS
> 
> I think its not possible to distribute crypto stuff in the stock kernel.
> 
> Am I wrong? 
> 
> > 	rmap
> 
> I need to see it running in production for more time.
> 
> >  Marcelo, there were some i2c updates included in the lmsensors package,
> > have they
> >  submitted those to you for integration into 2.4.19?
> 
> Nope. I could well integrate lm_sensors in the future.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Congrats Marcelo,

[Bill Davidsen]

On Tue, 26 Feb 2002, Dennis, Jim wrote:

>  Now I need to know about the status of several unofficial patches:
> 
> 	XFS
> 	LVM
> 	i2c
> 	Crypto
> 	FreeS/WAN KLIPS
> 	LIDS
> 	rmap

These have been addressed, let me add NGPT (next generation pthreads) to
that list. The IBM site says the patches have been accepted by Linus for
mainline code, it would be good to get these in, unless they need a higher
blessing than that!

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

RE: crypto (was Re: Congrats Marcelo,)

[Dennis, Jim]

> Andreas Dilger wrote:
>> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
>>>  Now I need to know about the status of several unofficial patches:

>>>       i2c
>>>       Crypto
>>>       FreeS/WAN KLIPS
>>>       LIDS
 
>> No idea.

> I would -love- to see crypto in the mainstream kernel.  Distribution of
> crypto software on kernel.org has been OK for a while now.

> Who knows what the kerneli guys, freeswan, etc. guys think.

> IMO it's time to get a good IPsec implementation in the kernel...

>	Jeff

 I think some people may have misinterpreted my question.  I was actually 
 asking about how soon the maintainers of these unofficial patches will
 be updating their patches to apply cleanly to 2.4.18 (and hopefully in
 conjunction with one another).  I wasn't actually asking when or if these
 would be merged into the mainstream.

 I understand that XFS is not slated for 2.4.x merging; and I presume that
the
 ACL and extended ACL stuff is also slated to remain separate.  I also
understand
 the wariness of the kernel maintainers regarding any inclusion of the
crypto
 code in mainstream given the ongoing U.S. and international political and
legal
 issues that are STILL associated with it.  (Who was it who said that
"reform
 is the enemy of revolution" --- like it or not that seems to be the case
with
 U.S. crypto policy; they've opened the doors enough for most practical
purposes
 leaving a spectre of doubt that they may still have the "right" to control
 the use and export of future cryptographic --- and by extension *other*
software
 --- technologies).  So I understand that the international and KLIPS
patches will
 probably be "unofficial" for the foreseeable future.

 The i2c work seems like a good candidate for inclusion (since lmsensors is
*THE*
 major user of these APIs and it requires the new version.

 As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
before Linus
 includes any of those into the mainstream.  I think it is sufficient that
he's willing 
 to accommodate the LSM (security module) to provide a common interface to
all of the 
 competing kernel hardening packages.  (I think a bit of consolidation
between the 
 international crypto patch and the LIDS patches might be in order, are they
each
 defining their own versions of the common hashing and encryption
algorithms?).

 The rmap patches are the ones which I would expect to cause the most
debate.  On the
 one hand it seems that they have significant performance and robustness
benefits
 (when the system is pushed to VM pressure) on the other hand I could
understand that
 Marcelo might be VERY reluctant to make such a deep change in a "stable"
series.
 (Linus took a lot of flack for earlier 2.4 VM changes and *he's* the
benevolent
 dictator! --- one can only imagine what will happen to any mortal that
would tempt
 fate so audaciously).  (Anyway, it seems to be a non-issue since you say
that Rik
 isn't even proposing their inclusion; I guess he has just been waiting for
an appropriate
 merge point in 2.5)

 So, I just wanted to know when the (minor) unofficial patches were getting
updated.
 Actually what I'd like is a focal point, perhaps a web site like the old
"big Mama" 
 patches (that Kurt Hewig? used to maintain), which would track and merge
these collections
 of unofficial patches.

 I'll check the FOLK (folk.sourceforge.net) pages ... [click, click]
 ... O.K. those were updated for 2.4.18rc2 so I guess they'll probably be
pretty durn
 close.

 Hmmm.  It seems that I'm rambling and wasting everyone's visual bandwidth.
I'll go 
 away now.  ;)

Re: crypto (was Re: Congrats Marcelo,)

[Chris Wright]

* Dennis, Jim (jdennis@snapserver.com) wrote:
<snip>
> As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
> before Linus includes any of those into the mainstream.  I think it is
> sufficient that he's willing to accommodate the LSM (security module)
> to provide a common interface to all of the competing kernel hardening
> packages.
<snip>

You may interested to know, LIDS has been ported to LSM, which is kept
up-to-date for stable 2.4 releases, and (for those with bitkeeper) all
2.5-pres/stable.

cheers,
-chris

RE: crypto (was Re: Congrats Marcelo,)

[Dennis, Jim]

 


> * Dennis, Jim (jdennis@snapserver.com) wrote:
> <snip>
>> As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
>> before Linus includes any of those into the mainstream.  I think it is
>> sufficient that he's willing to accommodate the LSM (security module)
>> to provide a common interface to all of the competing kernel hardening
>> packages.
> <snip>

> You may interested to know, LIDS has been ported to LSM, which is kept
> up-to-date for stable 2.4 releases, and (for those with bitkeeper) all
> 2.5-pres/stable.

> cheers,
> -chris

 Yes, I had read that.  Do you know of any effort to consolidate the 
 crypto libs in LIDS, patch-int, and FreeS/WAN KLIPS?  I'd like to think 
 that they can be maintained more efficiently and result in lower overhead
 and integration effort if the core crypto algorithms are consolidated
 among those three.

 (I remember someone found three? or four? different implementations of the
 same checksum code in the mainstream kernel a couple of years ago; I hope
 that's been fixed long since).

 (Any flames about my armchair coaching and pointed suggestions that I
 get in there and help with this are welcome --- off the list! I won't take 
 offense, I just don't want to burden everyone else's mailbox with that).

Re: crypto (was Re: Congrats Marcelo,)

[Chris Wright]

* Dennis, Jim (jdennis@snapserver.com) wrote:
> 
>  Yes, I had read that.  Do you know of any effort to consolidate the 
>  crypto libs in LIDS, patch-int, and FreeS/WAN KLIPS?

Sorry, I am not aware of such an effort.  You'd have to contact the LIDS
team, or the other projects you mentioned.  I'm just involved with the LSM
side ;-)

cheers,
-chris