Moving this to the appropriate list:
On Mon, 2003-07-21 at 23:27, Chris Ricker wrote:
With cipe-1.5.4, if you do
./configure --enable-protocol=3 (or just ./configure)
you get the exact same protocol in 1.5 that you get in 1.4. That interoperates with the cipe-1.4.x stuff RH ships currently
If you do
./configure --enable-protocol=4
you get the new protocol with all the new features. That doesn't interoperate.
Its a little more complicated than that in implementation. Specifically, the following is true:
Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They are mutually exclusive in the code. In addition, the two protocol types (3 and 4) are mutually exclusive in the code.
This means, to add it to the Red Hat Linux kernel as is, there would need to be 4 directories with virtually identical code, simply to account for all 4 possible modules. Headers cannot be shared in current state.
In order to clean this up (one source tree generates 4 modules in full build mode), the code would need a fairly massive rewrite (IMHO).
I came across all of this while dealing with Aurora. The big question is: how does the RH kernel team feel about adding four new directories to drivers/addon:
cipe3-bf/ cipe3-idea/ cipe4-bf/ cipe4-idea/
If they don't have a problem with doing that (I was planning on encapsulating them within a single "cipe" directory), the patches I'm doing for Aurora should work with RHL.
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
On Wed, 2003-07-23 at 14:39, Tom 'spot' Callaway wrote:
Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They are mutually exclusive in the code. In addition, the two protocol types (3 and 4) are mutually exclusive in the code.
This means, to add it to the Red Hat Linux kernel as is, there would need to be 4 directories with virtually identical code, simply to account for all 4 possible modules. Headers cannot be shared in current state.
Addendum: The cipe code also assumes that the userspace tools/daemon are built at the same time as the kernel modules. As such, it generates a "VERSION" string, which the userspace compares against the kernel module. If they don't match, it bails out.
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
On Wed, 23 Jul 2003, Tom 'spot' Callaway wrote:
Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They are mutually exclusive in the code. In addition, the two protocol types (3 and 4) are mutually exclusive in the code.
This means, to add it to the Red Hat Linux kernel as is, there would need to be 4 directories with virtually identical code, simply to account for all 4 possible modules. Headers cannot be shared in current state.
That's not new. Cipe 1.4.x also has both Blowfish and IDEA. Unless compiled with
./configure --enable-idea
it only includes Blowfish, just like with Cipe 1.5.x.
RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any reason why it would be necessary or even desirable to include IDEA support suddenly just because of moving to 1.5.x.
later, chris
On Wed, Jul 23, 2003 at 03:48:52PM -0600, Chris Ricker wrote:
On Wed, 23 Jul 2003, Tom 'spot' Callaway wrote:
Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They are mutually exclusive in the code. In addition, the two protocol types (3 and 4) are mutually exclusive in the code.
This means, to add it to the Red Hat Linux kernel as is, there would need to be 4 directories with virtually identical code, simply to account for all 4 possible modules. Headers cannot be shared in current state.
That's not new. Cipe 1.4.x also has both Blowfish and IDEA. Unless compiled with
./configure --enable-idea
it only includes Blowfish, just like with Cipe 1.5.x.
RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any reason why it would be necessary or even desirable to include IDEA support suddenly just because of moving to 1.5.x.
Indeed, IDEA is patent encumbered, we couldn't ship this at all.
joe
On Thu, 2003-07-24 at 03:52, Joe Orton wrote:
it only includes Blowfish, just like with Cipe 1.5.x.
RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any reason why it would be necessary or even desirable to include IDEA support suddenly just because of moving to 1.5.x.
Indeed, IDEA is patent encumbered, we couldn't ship this at all.
Both valid points. Attached are the four patches to add Cipe 1.5.4 support into the kernel. The cipe3 and cipe4 patch add the two cipe protocol trees, configured for blowfish. These patches include all relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed the check for VERSION_MAGIC, since IMHO, it was just useless to force the daemon to be built at the same time as the kernel modules. The third patch is simply a fixed version of Patch5000: linux-2.4.9-addon.patch The fourth patch is simply a fixed version of Patch10010: linux-2.4.1-compilefailure.patch.
All these patches obsolete the pre-existant core cipe patches in the RHL kernel tree (Patch5190-5193). Config files will need to be updated to point to CONFIG_CIPE3 and CONFIG_CIPE4 instead of CONFIG_CIPE.
This is also attached to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=68066.
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
I originally sent this on Jul 25th, 2003... but it got eaten by the "message too large" monster, and is likely still waiting approval from the list admin. This version does NOT have the attached patches, but they're on the bugzilla entry.
(Perhaps we should up the size restriction limit a bit on the -devel list to allow patches to be posted?)
On Thu, 2003-07-24 at 03:52, Joe Orton wrote:
it only includes Blowfish, just like with Cipe 1.5.x.
RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any reason why it would be necessary or even desirable to include IDEA support suddenly just because of moving to 1.5.x.
Indeed, IDEA is patent encumbered, we couldn't ship this at all.
Both valid points. Attached are the four patches to add Cipe 1.5.4 support into the kernel. The cipe3 and cipe4 patch add the two cipe protocol trees, configured for blowfish. These patches include all relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed the check for VERSION_MAGIC, since IMHO, it was just useless to force the daemon to be built at the same time as the kernel modules. The third patch is simply a fixed version of Patch5000: linux-2.4.9-addon.patch The fourth patch is simply a fixed version of Patch10010: linux-2.4.1-compilefailure.patch.
All these patches obsolete the pre-existant core cipe patches in the RHL kernel tree (Patch5190-5193). Config files will need to be updated to point to CONFIG_CIPE3 and CONFIG_CIPE4 instead of CONFIG_CIPE.
This is also attached to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=68066.
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
On Mon, Jul 28, 2003 at 03:06:15PM -0500, Tom 'spot' Callaway wrote:
(Perhaps we should up the size restriction limit a bit on the -devel list to allow patches to be posted?)
Or leave it the way it is to encourage aggressive use of bugzilla!
Both valid points. Attached are the four patches to add Cipe 1.5.4 support into the kernel. The cipe3 and cipe4 patch add the two cipe protocol trees, configured for blowfish. These patches include all relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed the check for VERSION_MAGIC, since IMHO, it was just useless to force the daemon to be built at the same time as the kernel modules.
With all your patches applied, what happens from the user perspective? How do they connect to a system only running protocol version 3? Ditto 4?
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Mon, 2003-07-28 at 16:21, Michael K. Johnson wrote:
On Mon, Jul 28, 2003 at 03:06:15PM -0500, Tom 'spot' Callaway wrote:
(Perhaps we should up the size restriction limit a bit on the -devel list to allow patches to be posted?)
Or leave it the way it is to encourage aggressive use of bugzilla!
It's nice having patches both on lists and in bugzilla, IMHO. Bugzilla helps to keep them from getting lost, but it's a lot easier to critique patches via mail where you can reply and quote the bits you want to critique.
Jeremy
On Mon, 2003-07-28 at 15:21, Michael K. Johnson wrote:
On Mon, Jul 28, 2003 at 03:06:15PM -0500, Tom 'spot' Callaway wrote:
(Perhaps we should up the size restriction limit a bit on the -devel list to allow patches to be posted?)
Or leave it the way it is to encourage aggressive use of bugzilla!
I know to use bugzilla, others may not. Perhaps the "message too big" response could point patch submissions to bugzilla?
Both valid points. Attached are the four patches to add Cipe 1.5.4 support into the kernel. The cipe3 and cipe4 patch add the two cipe protocol trees, configured for blowfish. These patches include all relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed the check for VERSION_MAGIC, since IMHO, it was just useless to force the daemon to be built at the same time as the kernel modules.
With all your patches applied, what happens from the user perspective? How do they connect to a system only running protocol version 3? Ditto 4?
Well, a kernel built with this (and CONFIG_CIPE3=m and CONFIG_CIPE4=m) generates two modules: cipcb.o (v3) cipdb.o (v4)
If you need to connect to a v3 machine, use the cipcb.o module, v4, the latter.
Admittedly, the userspace needs some fixups too. Basically, the cipe package needs to be split into a v3/v4 manner (think krb, but not quite so bad), so that you install what you need. However, getting the kernel to support it is the first step. I'm planning on doing the userspace work at some point this week. :)
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
On Mon, Jul 28, 2003 at 03:29:28PM -0500, Tom 'spot' Callaway wrote:
I know to use bugzilla, others may not. Perhaps the "message too big" response could point patch submissions to bugzilla?
Jeremy's response was probably right -- good to be able to review patches in email.
Well, a kernel built with this (and CONFIG_CIPE3=m and CONFIG_CIPE4=m) generates two modules: cipcb.o (v3) cipdb.o (v4)
If you need to connect to a v3 machine, use the cipcb.o module, v4, the latter.
Or, more to the purpose: cipcb<n> and cipdb<n> as interface names.
Admittedly, the userspace needs some fixups too. Basically, the cipe package needs to be split into a v3/v4 manner (think krb, but not quite so bad), so that you install what you need. However, getting the kernel to support it is the first step. I'm planning on doing the userspace work at some point this week. :)
No need to split into multiple cipe userspace packages (there's not a separate kernel package for each of the two cipe modules) -- it just needs to do the right thing automatically in each case.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
Observed that install guide from Severn miss riserfs module at install guide. There was a trik in Rh 9 that allow to instal on reiserfs, i just swich AltF2 format partitions using mkreiserfs, and to DiskDruid tell to mount only not to format. Severn miss reisefs.o during instal stage ... DiscDruid not allow to define mountpoint because i think reiserfs.o miss so /proc/filesystem not reports reiserfs.
I use lot of Rh's 7.3/8.0/9 in production instaled with that trick whithout any kind of problem why dont add reiserfs/xfs/jfs officialy in the list of diskdruid ?
Yes yes of course not pass bonnie++ or other tools ? Suse allows it, but i dont like suse :))
Can manage in future to reenable reiserfs (mean to add kernels' reiserfs.o to instal stage) ? Today trying Severn i was disappointed when i realise the trick not work anymore ...
Thanks a lot !
reiserfs is in kernel-unsupported, and we're discussing changes to the way we build the distro to deal with this issue.
We want to disambiguate "we expect this to work" from "we aren't so sure about this, and bug reports are likely to be WONTFIX"; the goal isn't to remove functionality and confuse people. :-) We're still working on this...
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Tue, Jul 29, 2003 at 07:42:43PM -0400, Balint Cristian wrote:
Observed that install guide from Severn miss riserfs module at install guide. There was a trik in Rh 9 that allow to instal on reiserfs, i just swich AltF2 format partitions using mkreiserfs, and to DiskDruid tell to mount only not to format. Severn miss reisefs.o during instal stage ... DiscDruid not allow to define mountpoint because i think reiserfs.o miss so /proc/filesystem not reports reiserfs.
I use lot of Rh's 7.3/8.0/9 in production instaled with that trick whithout any kind of problem why dont add reiserfs/xfs/jfs officialy in the list of diskdruid ?
Yes yes of course not pass bonnie++ or other tools ? Suse allows it, but i dont like suse :))
Can manage in future to reenable reiserfs (mean to add kernels' reiserfs.o to instal stage) ? Today trying Severn i was disappointed when i realise the trick not work anymore ...
Thanks a lot !
-- Life in itself has no meaning. Life is an opportunity to create meaning.
\|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/-- Rhl-devel-list mailing list Rhl-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list
On Wed, Jul 23, 2003 at 02:39:37PM -0500, Tom 'spot' Callaway wrote:
I came across all of this while dealing with Aurora. The big question is: how does the RH kernel team feel about adding four new directories to drivers/addon:
cipe3-bf/ cipe3-idea/ cipe4-bf/ cipe4-idea/
If they don't have a problem with doing that (I was planning on encapsulating them within a single "cipe" directory), the patches I'm doing for Aurora should work with RHL.
As has been pointed out, ditch the IDEA stuff, just build blowfish. That leaves version.
So how does the sysadmin choose which one is selected? Does the daemon autonegotiate which version module to load?
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
-
Balint Cristian -
Chris Ricker -
Jeremy Katz -
Joe Orton -
Michael K. Johnson -
Tom Callaway