This changeset is to fix several reiserfs problems which can be
fixed in non-intrusive way.
You can use bk receive to get it.
Diffstat:
Makefile | 2 +-
bitmap.c | 6 ++----
dir.c | 1 +
inode.c | 13 ++++++++-----
super.c | 2 +-
5 files changed, 13 insertions(+), 11 deletions(-)
patch and changelog:
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.587 -> 1.588
# fs/reiserfs/dir.c 1.12 -> 1.13
# fs/reiserfs/inode.c 1.38 -> 1.41
# fs/reiserfs/super.c 1.33 -> 1.34
# fs/reiserfs/Makefile 1.5 -> 1.6
# fs/reiserfs/bitmap.c 1.15 -> 1.16
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/04/05 [email protected] 1.588
# bitmap.c:
# fixed "unused variable" warning.
# super.c:
# Fix a mispelling in info message.
# Makefile:
# tail_conversion.o was specified twice in list of objects to build
# inode.c:
# Add forgotten metadata journaling.
# Fix a case where flag was not set at inode-read time which prevented
# 32bit uid/gid to work correctly.
# Fix a lookup problem on big-endian platforms.
# dir.c:
# Fix a case where atime were not updated when needed.
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/Makefile b/fs/reiserfs/Makefile
--- a/fs/reiserfs/Makefile Fri Apr 5 14:16:14 2002
+++ b/fs/reiserfs/Makefile Fri Apr 5 14:16:14 2002
@@ -9,7 +9,7 @@
O_TARGET := reiserfs.o
obj-y := bitmap.o do_balan.o namei.o inode.o file.o dir.o fix_node.o super.o prints.o objectid.o \
-lbalance.o ibalance.o stree.o hashes.o buffer2.o tail_conversion.o journal.o resize.o tail_conversion.o item_ops.o ioctl.o procfs.o
+lbalance.o ibalance.o stree.o hashes.o buffer2.o tail_conversion.o journal.o resize.o item_ops.o ioctl.o procfs.o
obj-m := $(O_TARGET)
diff -Nru a/fs/reiserfs/bitmap.c b/fs/reiserfs/bitmap.c
--- a/fs/reiserfs/bitmap.c Fri Apr 5 14:16:14 2002
+++ b/fs/reiserfs/bitmap.c Fri Apr 5 14:16:14 2002
@@ -139,10 +139,8 @@
/* preallocated blocks don't need to be run through journal_mark_freed */
void reiserfs_free_prealloc_block (struct reiserfs_transaction_handle *th,
unsigned long block) {
- struct super_block * s = th->t_super;
-
- RFALSE(!s, "vs-4060: trying to free block on nonexistent device");
- RFALSE(is_reusable (s, block, 1) == 0, "vs-4070: can not free such block");
+ RFALSE(!th->t_super, "vs-4060: trying to free block on nonexistent device");
+ RFALSE(is_reusable (th->t_super, block, 1) == 0, "vs-4070: can not free such block");
_reiserfs_free_block(th, block) ;
}
diff -Nru a/fs/reiserfs/dir.c b/fs/reiserfs/dir.c
--- a/fs/reiserfs/dir.c Fri Apr 5 14:16:14 2002
+++ b/fs/reiserfs/dir.c Fri Apr 5 14:16:14 2002
@@ -180,6 +180,7 @@
filp->f_pos = next_pos;
pathrelse (&path_to_entry);
reiserfs_check_path(&path_to_entry) ;
+ UPDATE_ATIME(inode) ;
return 0;
}
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c Fri Apr 5 14:16:14 2002
+++ b/fs/reiserfs/inode.c Fri Apr 5 14:16:14 2002
@@ -745,8 +745,12 @@
if (retval) {
if ( retval != -ENOSPC )
printk("clm-6004: convert tail failed inode %lu, error %d\n", inode->i_ino, retval) ;
- if (allocated_block_nr)
+ if (allocated_block_nr) {
+ /* the bitmap, the super, and the stat data == 3 */
+ journal_begin(&th, inode->i_sb, 3) ;
reiserfs_free_block (&th, allocated_block_nr);
+ transaction_started = 1 ;
+ }
goto failure ;
}
goto research ;
@@ -933,9 +937,6 @@
// (directories and symlinks)
struct stat_data * sd = (struct stat_data *)B_I_PITEM (bh, ih);
- /* both old and new directories have old keys */
- //version = (S_ISDIR (sd->sd_mode) ? ITEM_VERSION_1 : ITEM_VERSION_2);
-
inode->i_mode = sd_v2_mode(sd);
inode->i_nlink = sd_v2_nlink(sd);
inode->i_uid = sd_v2_uid(sd);
@@ -956,6 +957,7 @@
else
set_inode_item_key_version (inode, KEY_FORMAT_3_6);
REISERFS_I(inode)->i_first_direct_byte = 0;
+ set_inode_sd_version (inode, STAT_DATA_V2);
}
pathrelse (path);
@@ -1218,7 +1220,8 @@
struct reiserfs_iget4_args *args;
args = opaque;
- return INODE_PKEY( inode ) -> k_dir_id == args -> objectid;
+ /* args is already in CPU order */
+ return le32_to_cpu(INODE_PKEY(inode)->k_dir_id) == args -> objectid;
}
struct inode * reiserfs_iget (struct super_block * s, const struct cpu_key * key)
diff -Nru a/fs/reiserfs/super.c b/fs/reiserfs/super.c
--- a/fs/reiserfs/super.c Fri Apr 5 14:16:14 2002
+++ b/fs/reiserfs/super.c Fri Apr 5 14:16:14 2002
@@ -765,7 +765,7 @@
if ( rs->s_v1.s_root_block == -1 ) {
brelse(bh) ;
printk("dev %s: Unfinished reiserfsck --rebuild-tree run detected. Please run\n"
- "reiserfsck --rebuild-tree and wait for a completion. If that fais\n"
+ "reiserfsck --rebuild-tree and wait for a completion. If that fails\n"
"get newer reiserfsprogs package\n", s->s_id);
return 1;
}
BK changeset:
This BitKeeper patch contains the following changesets:
1.588
## Wrapped with gzip_uu ##
begin 664 bkpatch2245
M'XL(`&6WK3P``[58:V_CMA+]'/V*N2E0)&ULBR(I2RX2)-W-MD'Z"/91H$`!
M@9(HFXTL&J*<;'IU__L=4G(WWJ2)G:T=PV)L<G0X<V;.4%_!!R/KR=ZTEK+R
MOH(?M6DF>Z*:IJ+*AY682W-GAIF>XV]OM<;?1C,]ER,W?Y1>)[>ZOA[54J$5
M.BA5M?PX"(;<P^E7HLEF<"-K,]DC0_KW-\W=0D[VWI[_\.&GL[>>=WP,KV9X
M0_E.-G!\[#6ZOA%E;DY%,RMU-6QJ49FY;(1%T?X]M0U\/\`_3L;4YV%+0I^-
MVXSDA`A&9.X'+`J9YW">/K*?SRTQG_LQ(Y2T?A3'W'L-9,BC"/Q@Y+.1SX'0
M"?<G//C69Q/?AW\T#-]R&/C>]_#O;N25ET&JFKE8#+,)C@$*]5'FL+^LE@:O
M-Z)6(BWE/MR*NE+5=(B3S'(AZ]7\-^HC")@KLY`E!FH*JL)WH0&A&S&5=L'/
MXEH6JI3=BD:H,LET96.H<`<:;1O`]9DJ%-ZSN569M&9*91K0!>CT3YDU!K<.
MZ5*5.5I1E<[E"L)9GD.AZZEN&EF!]44N&@%_ZF5=B;('O4*:"2/A=B9K"44I
MIN[>E6[`($]$TQD>U%(@#C6W,Q62:U'+&UDU,G>&:(`N@Z7*1U.56U26K9#I
MND:8Y=W]NY5:7R\7N%ZC$^>@*_3V=""K7(D*%J5H$/?<V!6Y^LRE]X"*#HH=
M6JC+!>X/'84_5E!)F<M\Z%T"(73,O*M/O/<&6[X\SQ>^=P(+FU&/$ZPP?5KB
M8!76>USC/@U:ZOLQ;0N>QMDX8"DOHC0.TG_F]A-&N_SA)&X#'I#QYMA6I'Z(
M#7G?%BP:QR+F-)=Q5G"Q(;9UHPX;]X.@);AALCDV%^J'P&+"6QZ&<3QF:9K'
MM`A)L2&P>Q;[BL/"EL6!OP6J/J4>X`IX'+5Y+FD<9RR/\ZP@;--@KMGLD#'T
M%Z,LVH)G?;U91T9;']V.'DO#**<19UQ$8[_8%-F:S0Y9&/`V9&.?.O5XC)-6
M2':2&R^U&OH^B5C4!F,_($Y<PC5I87Q"XN>EA<"`[$1:OKS47T*7^+_"H+YU
M;RQ35X]&YP7E[C4)@'@7[K-,12FJ3")(]6EH&G0;7F?"S*096EA%(>L`1P\W
MURL.CFIIU%_.5"/GB5[8E4JC.N`5Q2`K\(L'-%N5ERUHMEV9\VY4K4_G:'6X
M,,NAS)=/&0LB_*`<RQL)0^K81<+/.Y=@@\XE@`';";V>[550%%UI?H(]JTV_
MB#TL`(;T81P"#X4;WKXY^^G=^<%_FMG@I$E<C3F"_1LS8)BJ$VCJ.]LA(;D+
M]!:DI<ZN;4]0Z4I^Q`S`%@-R>8,YL7_XW7V#RB2U7!J[.SA8,^YL'`$Y1-*`
MO[K9&&^6B<IU"^Y69HE=C)MK+7]./"<?6[!N"P'SND6G&RA70*PQSE`?QHS[
M'>'H>CTC$Q9N5,]VTRJ_L#/KE/@)$CHOO("!%R2RI<LRY</5Z[/WY\G9^XN?
MD2]6=P_A8:1[0=XBUENU!=Y<&%V=&LS'YWJ!@$2<4-YB@:&1BS6-UV,=3'R^
M47'Y][4KV[)]OP0:HZFG0MQO_V4B%9!.IO#:%9K1-R#JJ0%E0)3VM')G5?35
MU0?0=2YK^&;DIM6R046"4M(@:722+98'%[_\^OH\N;H\_[UGR>#D.D'^)2IW
M-<29'9ST2JQRY-"+>SWT<]LYQL:7^>OQ1?W8K#>A.XOO%Q\&GST*(C,HX]&.
MF!'3$*AW$?,(^;&'J!-G+#%YTG<ET$7Y"-Z]/WN?8(DX2WX+#K\DJ)3';;<G
M%U2R'E2V44?`=]5P;O`H`,NQ.W[L)B)C9D-Q82_4V]NS2:@*.!`E:J^5AL2)
M<%+5A_!?_'T/$[F9R?X9S)$;]\J.3NO^;9");A>8G=1F-B[K-Y2D<JJJ@Z^;
MV5%/UA.5F/0(J"W^B"+&>H'3G6,%IK.N$K176XTZ!H)S.HC_>R`4_?EH"Z'8
MZI2V(?T>.:59:R'C_;,TRM;I%TZ"#31C9^>=YQ^&74)WQ'R"??VF7\2^L&.?
MN\#::W]E'UO.`=8T=[P:V-.-8]JMP#J&F6.+HIXO2FFY,H2+`CF(_"OPK&/^
=J/8_/8'-9C*[-LOYL<`V+\K3POL_D.3+5_45````
`
end
On Sat, 6 Apr 2002, Hans Reiser wrote:
>
> This changeset is to fix several reiserfs problems which can be
> fixed in non-intrusive way.
Please don't use bk patches, they have turned out to be pretty much
unusable.
Either make a (controlled) bk tree available for pulling, or just use
old-fashioned patches.
Linus
On Fri, Apr 05, 2002 at 01:48:30PM -0800, Linus Torvalds wrote:
>
> On Sat, 6 Apr 2002, Hans Reiser wrote:
> >
> > This changeset is to fix several reiserfs problems which can be
> > fixed in non-intrusive way.
>
> Please don't use bk patches, they have turned out to be pretty much
> unusable.
I suspect that the problem is that BK won't let you accept a patch unless
the receiving repository has the parent of the patch. In other words,
this won't work:
bk clone bk://linux.bkbits.net/linux-2.5
<make some changes>
bk commit (or bk citool) # creates changeset 1.800
<make some changes>
bk commit (or bk citool) # creates changeset 1.801
# Now you want to send the second patch to Linus so you do a:
bk send -r+ - | mail [email protected]
That will fail when Linus tries to accept the patch, because he doesn't
have your 1.800.
The easiest thing is to do what he suggests:
> Either make a (controlled) bk tree available for pulling, or just use
> old-fashioned patches.
and if you want to go the "tree for pulling", you can either point him at
a BK url you maintain, or you are welcome to go grab resierfs.bkbits.net
and stash it there. See http://www.bitkeeper.com/Hosted.html for information
on how to set up a project here.
At some point, we'll package up the whole bkbits.net infrastructure as an
installable RPM (not the project data, the infrastructure), and you'll be
able to do this at resierfs.bkbits.kernel.org or something like that, but
right now we're just too overworked to do so.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
I am confused, the bk patches look like they have normal patches at the
top of them. Does he just need to use patch -p1 or is there a deeper
screwiness to these patches that he refers to?
We did this because my security/sysadmin specialist (flx) is not
enthusiastic about having a semi-closed source network service offering
process running on the machine which holds our source code and website
without any IP filters guarding it. Especially when it is as
complicated as a version control system needs to be.
We were planning on setting up a clone for non-Namesys users outside our
firewall, but we need for Linus's access to be just as secure as ours.
I am not sure what to do, let's see what flx says.
Hans
PS for Larry (Persons not interested in licensing issues should not read
further)
Keeping source code secret is the worst part of the proprietary model.
It prevents knowledge from accumulating, and it is an abuse of the
original intention of copyright law, which was to encourage people to
not keep knowledge secret. I know that piracy has caused you to keep
the source code secret, but piracy is a problem for all software (even
GPL software, as proprietary software vendors frequently steal it).
Please don't let a few bad experiences lead you down the trade secret
route that copyright and patent laws were designed to let us escape from.
Secret source code is a form of social lockout, and avoiding that
lockout is the civil rights issue of our day. This will only become
more and more important in the coming generations, as our shadows in
cyberspace become more solid, and firmer in their replication of our
evils. Lockout of programs, and of persons who modify programs, is
going to be the most important civil rights issue of your lifetime. Are
you sure you are standing where you want to stand on that issue?
Another model you might consider, one which would probably make you more
money, make us happier, and better avoid "freeloaders", would be to make
bitkeeper free for use with free software only. This would be rather
similar to what I use for reiserfs, which is free for use with free
operating systems only, and available for a fee for all others. It
allows you to "do unto others as they would do unto you" (The Reiser
Rule ;-) ).
Hans
Larry McVoy wrote:
>On Fri, Apr 05, 2002 at 01:48:30PM -0800, Linus Torvalds wrote:
>
>>On Sat, 6 Apr 2002, Hans Reiser wrote:
>>
>>>This changeset is to fix several reiserfs problems which can be
>>>fixed in non-intrusive way.
>>>
>>Please don't use bk patches, they have turned out to be pretty much
>>unusable.
>>
>
>I suspect that the problem is that BK won't let you accept a patch unless
>the receiving repository has the parent of the patch. In other words,
>this won't work:
>
> bk clone bk://linux.bkbits.net/linux-2.5
> <make some changes>
> bk commit (or bk citool) # creates changeset 1.800
> <make some changes>
> bk commit (or bk citool) # creates changeset 1.801
>
> # Now you want to send the second patch to Linus so you do a:
> bk send -r+ - | mail [email protected]
>
>That will fail when Linus tries to accept the patch, because he doesn't
>have your 1.800.
>
>The easiest thing is to do what he suggests:
>
>>Either make a (controlled) bk tree available for pulling, or just use
>>old-fashioned patches.
>>
>
>and if you want to go the "tree for pulling", you can either point him at
>a BK url you maintain, or you are welcome to go grab resierfs.bkbits.net
>and stash it there. See http://www.bitkeeper.com/Hosted.html for information
>on how to set up a project here.
>
>At some point, we'll package up the whole bkbits.net infrastructure as an
>installable RPM (not the project data, the infrastructure), and you'll be
>able to do this at resierfs.bkbits.kernel.org or something like that, but
>right now we're just too overworked to do so.
>
On Sat, Apr 06, 2002 at 04:00:37PM +0400, Hans Reiser wrote:
> I am confused, the bk patches look like they have normal patches at the
> top of them.
If you just want to send him regular patches, use bk export -tpatch.
That's sort of a lame way to go if you are using BK on both ends,
you're going to end up merging your changes with your changes when
you pull from Linus' tree. There are lots of reasons why this isn't
a good idea.
> We were planning on setting up a clone for non-Namesys users outside our
> firewall, but we need for Linus's access to be just as secure as ours.
bk help url, then look at
bk://<user>@<host>
Connects to <host> using ssh, assumes that bkd is the
login shell. The home directory of <user> must be the
root of the repository.
then you can make a login shell that looks like
#!/bin/sh
exec bk bkd -xcd
and you have an ssh based login which can only look at data in that
directory. This is how the write path on bkbits.net works.
> Another model you might consider, one which would probably make you more
> money, make us happier, and better avoid "freeloaders", would be to make
> bitkeeper free for use with free software only. This would be rather
> similar to what I use for reiserfs, which is free for use with free
> operating systems only, and available for a fee for all others. It
> allows you to "do unto others as they would do unto you" (The Reiser
> Rule ;-) ).
We are dealing with various commercial organizations who play games
with the checkin comments so that they can use BK for free and not give
up any information. Technically, it's a violation of the license if
they do that, but proving that they are doing it just isn't worth it.
What I'm tempted to do is to figure out a reasonable way to force free
uses to make their changes publically available. More like sourceforge,
if you use their service, anyone can get at your source. The problem
is that we can't force all the changes out into the open immediately,
people may have good reasons to hide (security changes, for example),
along with bad reasons (they're freeloaders).
Allowing free use of BK with free software only doesn't solve anything.
We have lots of people doing that and still hiding their changes
behind empty (or "fixed") checkin comments. It's only the commercial
organizations who are a problem. I'd really like to force those changes
out in the open if they aren't going to pay. The whole point of the
openlogging stuff was to get people to work out in the open.
I've thought a bit about some sort of answer which addresses this and
I'm curious to see what people would think if the rule were that your
changes had to show up on a public server within a given time period
(a month? 2 months? 3 months?). In other words, factor in a reasonable
ability to work in privacy but make it be limited enough that it only
works for truly free software.
My definition of free software is anything where the source is publically
available. It's sometimes called "Open Source". Open source software
where you can't get at the source is lame.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Hello!
On Sat, Apr 06, 2002 at 09:01:57AM -0800, Larry McVoy wrote:
> > I am confused, the bk patches look like they have normal patches at the
> > top of them.
> If you just want to send him regular patches, use bk export -tpatch.
> That's sort of a lame way to go if you are using BK on both ends,
> you're going to end up merging your changes with your changes when
> you pull from Linus' tree. There are lots of reasons why this isn't
> a good idea.
In fact, per one of the original 'BK Patches sending' HOWTO,
we are including output of bk export -tpatch ... stuff prior to
bk send ... - stuff.
So that people who want to get the diff, can get it without silly tricks.
Bye,
Oleg
Larry McVoy wrote:
>
>>Another model you might consider, one which would probably make you more
>>money, make us happier, and better avoid "freeloaders", would be to make
>>bitkeeper free for use with free software only. This would be rather
>>similar to what I use for reiserfs, which is free for use with free
>>operating systems only, and available for a fee for all others. It
>>allows you to "do unto others as they would do unto you" (The Reiser
>>Rule ;-) ).
>>
>
>We are dealing with various commercial organizations who play games
>with the checkin comments so that they can use BK for free and not give
>up any information. Technically, it's a violation of the license if
>they do that, but proving that they are doing it just isn't worth it.
>What I'm tempted to do is to figure out a reasonable way to force free
>uses to make their changes publically available.
>
This would be good to do.
> More like sourceforge,
>if you use their service, anyone can get at your source. The problem
>is that we can't force all the changes out into the open immediately,
>people may have good reasons to hide (security changes, for example),
>along with bad reasons (they're freeloaders).
>
Better this inconvenience than hiding the source code....
>
>
>Allowing free use of BK with free software only doesn't solve anything.
>We have lots of people doing that and still hiding their changes
>behind empty (or "fixed") checkin comments. It's only the commercial
>organizations who are a problem. I'd really like to force those changes
>out in the open if they aren't going to pay. The whole point of the
>openlogging stuff was to get people to work out in the open.
>
Umm, I usually use "comment" as my comment for anything not a bugfix,
but it has nothing to do with your license and fear of people reading
it, it is purely that my comments go into the source code unless it is a
bugfix (bugfixes should have user emails attached to them, etc.).
>
>
>I've thought a bit about some sort of answer which addresses this and
>I'm curious to see what people would think if the rule were that your
>changes had to show up on a public server within a given time period
>(a month? 2 months? 3 months?). In other words, factor in a reasonable
>ability to work in privacy but make it be limited enough that it only
>works for truly free software.
>
I'd be happy.
>
>
>My definition of free software is anything where the source is publically
>available. It's sometimes called "Open Source". Open source software
>where you can't get at the source is lame.
>
Call it accessible source, this is my term which allows for pay for use
software whose source code is available for all to read. If you want to
require the software to be free as well, then call it free and
accessible source. (But please don't forbid it from being pay for use
as well as free like reiserfs is.....)
I believe that the antitrust laws should be interpreted as requiring
software source code to be accessible for any software for which there
might be a market for improvements to it. This of course assumes that
the government has any intention of enforcing the anti-trust laws....
which the current administration surely does not.
Hans
Hans Reiser <[email protected]> writes:
> Another model you might consider, one which would probably make you
> more money, make us happier, and better avoid "freeloaders", would be
> to make bitkeeper free for use with free software only. This would be
> rather similar to what I use for reiserfs, which is free for use with
> free operating systems only,
Really? I thought ReiserFS was released under the GPL. Is this no
longer the case?
--
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
> > Another model you might consider, one which would probably make you
> > more money, make us happier, and better avoid "freeloaders", would be
> > to make bitkeeper free for use with free software only. This would be
> > rather similar to what I use for reiserfs, which is free for use with
> > free operating systems only,
>
> Really? I thought ReiserFS was released under the GPL. Is this no
> longer the case?
Because something is GPL doesn't mean it is free dollar wise. GPL is free
as in free speech not free beer.
James Simmons <[email protected]> writes:
>> > Another model you might consider, one which would probably make you
>> > more money, make us happier, and better avoid "freeloaders", would be
>> > to make bitkeeper free for use with free software only. This would be
>> > rather similar to what I use for reiserfs, which is free for use with
>> > free operating systems only,
>>
>> Really? I thought ReiserFS was released under the GPL. Is this no
>> longer the case?
>
> Because something is GPL doesn't mean it is free dollar wise. GPL is free
> as in free speech not free beer.
That's not my point. Of course you can charge for GPLed software, or,
as the copyright holder, offer different licensing options for a fee.
However, if you release software under the GPL, you do not prevent
people from using it on proprietary operating systems.
--
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
Florian Weimer wrote:
[...]
> >> > rather similar to what I use for reiserfs, which is free
> for use with
> >> > free operating systems only,
> >>
> >> Really? I thought ReiserFS was released under the GPL. Is this no
> >> longer the case?
> >
> > Because something is GPL doesn't mean it is free dollar
> wise. GPL is free
> > as in free speech not free beer.
>
> That's not my point. Of course you can charge for GPLed software, or,
> as the copyright holder, offer different licensing options for a fee.
>
> However, if you release software under the GPL, you do not prevent
> people from using it on proprietary operating systems.
well, technically that's true. However they would not be able to link
it into the proprietary operating system and then distribute it without
violating the GPL.
So the only ways to put reiserFS on (say) Win2K would be to:
- Pay for and get a separate, non-GPL license from Hans Reiser and
his team, which is perfectly legitimate for them to do as the
copyright holders,
- or, implement it in _user-space_ as an entirely GPL'ed application.
Obviously this second option would be difficult, I don't know
if Win2K supports user-space filesystems at all. At the least, it
would have negative performance and reliability implications...
- or, do whatever you want but never distribute it at all.
Not to speak for Mr. Reiser, but I believe that's what he meant when
he said it's free for use with free operating systems only.
Finally, that second option could be even more difficult... I hear
MS has recently changed the terms of their C run-time-library license
to forbid use by GPLed code. If so, you'd have to use a different C
library for Windows...
Torrey Hoffman
"Torrey Hoffman" <[email protected]> writes:
> well, technically that's true. However they would not be able to link
> it into the proprietary operating system and then distribute it without
> violating the GPL.
Are you sure? Here's a quote from the GPL:
| However, as a special exception, the source code distributed need not
| include anything that is normally distributed (in either source or
| binary form) with the major components (compiler, kernel, and so on)
| of the operating system on which the executable runs, unless that
| component itself accompanies the executable.
Modules for proprietary kernels seem to be okay, don't they?
> - or, implement it in _user-space_ as an entirely GPL'ed application.
I don't see the user space requirement.
> Finally, that second option could be even more difficult... I hear
> MS has recently changed the terms of their C run-time-library license
> to forbid use by GPLed code.
This is extremely unlikely, as Microsoft is selling its own version of
an operation system with GNU components. ;-)
--
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
> | binary form) with the major components (compiler, kernel, and so on)
> | of the operating system on which the executable runs, unless that
> | component itself accompanies the executable.
>
> Modules for proprietary kernels seem to be okay, don't they?
It doesnt normally accompany the executable - thats an irrelevant ite,
> > Finally, that second option could be even more difficult... I hear
> > MS has recently changed the terms of their C run-time-library license
> > to forbid use by GPLed code.
>
> This is extremely unlikely, as Microsoft is selling its own version of
> an operation system with GNU components. ;-)
Microsoft are not required to obey their own licenses