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.)
Followup to: <[email protected]>
By author: "Dennis, Jim" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Contratulations on your first "official" kernel release.
>
Third, actually. 2.4.16 .17 .18 were all Marcelo.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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/
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 |
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
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.
On Tue, 2002-02-26 at 16:40, [email protected] 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
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: [email protected]
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/
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
> 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.
On February 26, 2002 10:47 pm, Robert Love wrote:
> On Tue, 2002-02-26 at 16:40, [email protected] 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
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:[email protected]
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
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: [email protected]
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: [email protected]
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
> 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. ;)
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. ;-)
--
[email protected]
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
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: [email protected]
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
> 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.
* Dennis, Jim ([email protected]) 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
> * Dennis, Jim ([email protected]) 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).
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?
--
[email protected]
* Dennis, Jim ([email protected]) 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
>> 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.
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 <[email protected]>
To: Martin J. Bligh <[email protected]>
Cc: <[email protected]>
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?
>
> --
> [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
Robert Love <[email protected]> :
[...]
> 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.
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 [email protected]
> 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 | [email protected]
/\/\|=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!
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/
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 | [email protected]
/\/\|=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!
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/
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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.
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
> 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
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
> > 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
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
> > 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)
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...
Marcelo writes:
> I think its not possible to distribute crypto stuff in the stock kernel.
> Am I wrong?
Some years ago I submitted a patch to include the loop device
in the default kernel, and that generated a lot of mail explaining
why this would lead to terrible problems. But Linus took the patch
and I have not heard of political problems.
Nobody knows for sure, and the rules are unclear, but for the time
being maybe it suffices to judge submissions on technical merit,
without worrying too much about politics.
Andries
Bill Davidsen <[email protected]> :
[...]
> 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
On Fri, Mar 01, 2002 at 09:30:01AM +0000, [email protected] wrote:
> Marcelo writes:
>
> > I think its not possible to distribute crypto stuff in the stock kernel.
> > Am I wrong?
>
> Some years ago I submitted a patch to include the loop device
> in the default kernel, and that generated a lot of mail explaining
> why this would lead to terrible problems. But Linus took the patch
> and I have not heard of political problems.
>
> Nobody knows for sure, and the rules are unclear, but for the time
> being maybe it suffices to judge submissions on technical merit,
> without worrying too much about politics.
>
Linus may have taken the loop device, but he doesn't have any encryption in
there AFAIK...
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Stephen. Seen M lately?
> Hi,
> FYI crypto is included in (Net|Free|Open)BSD source releases and I don't
> believe it is an issue for them.
> skd
OpenBSD is maintained in Canada. IIRC the FreeBSD IPSec patches started in
Japan, but I guess they have been merged into the mainstream. I don't know
about NetBSD.
However, the point is well taken. If our *BSD freeware OS' have been
successfully
shipping with IPSec and other advanced crypto, from the U.S. outbound than
it's a
precedent we may be able to follow. Also the Debian project seems to be
moving in
that direction (including crypto in their mainstream distro).
Obviously I opened a can of worms with my question. I just wanted to know
when
the unofficial patches would be sync with 2.4.18 (so I could fetch and
apply them
without having to wrangle addition .rej files; since I a number of local
patches to
apply and wrangle *their* rejects is enough work already).
Clearly there's alot of pent up demand to include more stuff in the
mainstream.
I can understand Marcelo's conservatism (and Linus'). So the various
branch trees
that are popping up. This latest one by Jorg Prante (sorry of the the lack
of
proper diacriticals) is a nice base, with XFS, rmap, Ingo's O(1) scheduler,
KLIPS
and patch-int, and quite a few others. It isn't as outrageous as FOLK and
it uses
the GR (getrewted) patches rather than LIDS. However, as I say, it's a
nice base
for someone who wants to be a few steps off the mainstream.
> 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.
In regards to crypto code in the kernel, read the legal advise given to
Debian: http://www.debian.org/legal/cryptoinmain
Sounds pretty simple and basically we are free to put crypto into code
released from the US, we just need to make the proper notification.
Same steps that were taken last year for the LK mirrors, all of which
should post a summary statement to this effect.
David
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
"Dennis, Jim" <[email protected]> writes:
>> FYI crypto is included in (Net|Free|Open)BSD source releases and I don't
>> believe it is an issue for them.
>
>> skd
>
> OpenBSD is maintained in Canada.
Does it really matter?
When most people download something from ftp.openbsd.com, the packets
travel through US territory. ;-)
--
Florian Weimer [email protected]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898