[PATCH] Added CONFIG_VFAT_FS_DUALNAMES option

Thanks to everyone who helped with the testing of the previous round
of VFAT patent workaround patches.

I've posted a new set of patches today which tries to address some of
the technical problems found in the last patch.

The new patches:

  - work with Win98
  - work with Jan's IOneIt MP3 player
  - work with all the other FAT capable devices I have available for
    testing
  - work with existing copies of mtools

The remaining issues that I am aware of are:

  - There is a cosmetic issue with the DOS command prompt under
    Win98. A directory listing works, but displays garbage in the
    column where a 8.3 short filename would normally go

  - Similarly, under WinXP, a "dir/x" will show garbage in the 8.3
    column. For example: http://samba.org/~tridge/dir_test.png

  - mtools has a similar cosmetic issue, which is fixed with a small
    patch

  - devices which only support 8.3 filenames will not be able to see
    or use files created with long names with the patch enabled

  - There is a very small chance of WinXP bluescreening if two files
    in the same directory have the same 11 dummy bytes, and are
    accessed in quick succession. The chances of this happening is
    approximately 80x smaller than with the previous patch. As
    previously noted, this is a very difficult problem to reproduce,
    and in fact nobody has managed to reproduce it without modifying
    the patch to use a much smaller number of random bits.

  - Similarly, there is a small chance that chkdsk on Windows will
    rename one file in a directory if they happen to have the same 11
    byte dummy values. The probability of this happening is
    approximately 80x lower than with the previous patch.

Some people have also asked that this patch change the name of the
filesystem to 'lfat' or similar. I have not included that change in
this patch as I think it is counter productive. Instead I have added a
printk_once() to produce a warning like this:

  VFAT: not creating 8.3 short filenames for long names

when the first long filename is created on a VFAT filesystem with this
patch enabled.

The reason I think this is a better option than a filesystem name
change is that a name change will break a unknown number of userspace
tools, scripts and config files. For example, desktop tools for
mounting filesystems, scripts that use -t vfat, module configuration
options in /etc could all be broken without any ability to give the
user feedback on why it broke.

If you have a FAT capable device that you want to test for
compatibility with the new patches, please have a look at the
'Testing' section of the following README:

  http://kernel.org/pub/linux/kernel/people/tridge/VFAT/README

It gives details on how you can do testing without having to change
your kernel.

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

[Boaz Harrosh-5]

On 07/21/2009 06:37 AM, tridge@... wrote:

> Thanks to everyone who helped with the testing of the previous round
> of VFAT patent workaround patches.
>
> I've posted a new set of patches today which tries to address some of
> the technical problems found in the last patch.
>
> The new patches:
>
>   - work with Win98
>   - work with Jan's IOneIt MP3 player
>   - work with all the other FAT capable devices I have available for
>     testing
>   - work with existing copies of mtools
>
> The remaining issues that I am aware of are:
>
>   - There is a cosmetic issue with the DOS command prompt under
>     Win98. A directory listing works, but displays garbage in the
>     column where a 8.3 short filename would normally go
>
>   - Similarly, under WinXP, a "dir/x" will show garbage in the 8.3
>     column. For example: http://samba.org/~tridge/dir_test.png
>

I guess you tried putting a zero at first char and it breaks everybody?

>   - mtools has a similar cosmetic issue, which is fixed with a small
>     patch
>
>   - devices which only support 8.3 filenames will not be able to see
>     or use files created with long names with the patch enabled
>
>   - There is a very small chance of WinXP bluescreening if two files
>     in the same directory have the same 11 dummy bytes, and are
>     accessed in quick succession. The chances of this happening is
>     approximately 80x smaller than with the previous patch. As
>     previously noted, this is a very difficult problem to reproduce,
>     and in fact nobody has managed to reproduce it without modifying
>     the patch to use a much smaller number of random bits.
>

I guess (35^6)*8*7 is not that bad

>   - Similarly, there is a small chance that chkdsk on Windows will
>     rename one file in a directory if they happen to have the same 11
>     byte dummy values. The probability of this happening is
>     approximately 80x lower than with the previous patch.
>

What if we had a user mode utility that does these short-names
renames that a user can optionally run after umount? since it
only writes the (random) short-names it's also safe.

Kind of the cop that can read and the cop that can write e-literacy
problem, No?

> Some people have also asked that this patch change the name of the
> filesystem to 'lfat' or similar. I have not included that change in
> this patch as I think it is counter productive. Instead I have added a
> printk_once() to produce a warning like this:
>
>   VFAT: not creating 8.3 short filenames for long names
>
> when the first long filename is created on a VFAT filesystem with this
> patch enabled.
>
> The reason I think this is a better option than a filesystem name
> change is that a name change will break a unknown number of userspace
> tools, scripts and config files. For example, desktop tools for
> mounting filesystems, scripts that use -t vfat, module configuration
> options in /etc could all be broken without any ability to give the
> user feedback on why it broke.
>
> If you have a FAT capable device that you want to test for
> compatibility with the new patches, please have a look at the
> 'Testing' section of the following README:
>
>   http://kernel.org/pub/linux/kernel/people/tridge/VFAT/README
>
> It gives details on how you can do testing without having to change
> your kernel.
>
> Cheers, Tridge
> --

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

[Pavel Machek]

>   - Similarly, there is a small chance that chkdsk on Windows will
>     rename one file in a directory if they happen to have the same 11
>     byte dummy values. The probability of this happening is
>     approximately 80x lower than with the previous patch.

The "small chance" seems to be 90% for 30000 files in directory. And
no, it is probably not 80x lower. Do the math.
                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Pavel Machek]

> >   - Similarly, there is a small chance that chkdsk on Windows will
> >     rename one file in a directory if they happen to have the same 11
> >     byte dummy values. The probability of this happening is
> >     approximately 80x lower than with the previous patch.
> >
>
> What if we had a user mode utility that does these short-names
> renames that a user can optionally run after umount? since it
> only writes the (random) short-names it's also safe.

Actually, why not having dosfsck creating _matching_ short names for
long names? As it only writes short names, it should be safe :-).
                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Jan Engelhardt-3]

On Tuesday 2009-07-21 11:16, Boaz Harrosh wrote:
>>   - Similarly, there is a small chance that chkdsk on Windows will
>>     rename one file in a directory if they happen to have the same 11
>>     byte dummy values. The probability of this happening is
>>     approximately 80x lower than with the previous patch.
>
>What if we had a user mode utility that does these short-names
>renames that a user can optionally run after umount? since it
>only writes the (random) short-names it's also safe.

Mm, user-mode. tridgefat could trigger a usermode process at open(2)
time to rebuild the short name with traditional semantics to counter
the 'breakage' induced by random 8.3 names.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Boaz,

 > I guess you tried putting a zero at first char and it breaks everybody?

It works with some devices, but with many it doesn't. A space followed
by a nul works with quite a lot of devices, but not enough (the last
patch used a space followed by a nul).

I went to a large electronics store and told them I wanted to buy
devices that didn't work with my computer. They were very helpful, and
as a result I was able to test a lot of devices. That is what led to
the design of this patch (plus the feedback from people like Jan and
his IOneIt MP3 player).

 > I guess (35^6)*8*7 is not that bad

yes, but luckily For the WinXP bluescreen the probability of the crash
is actually much lower than that figure would give. With the same
modelling assumptions of WinXP memory slots for 8.3 entries that Paul
used for the last patch, it comes out as less than a 1 in 10k chance
for a full directory (ie. 32767 long filenames). For 100 files in a
directory it is around 1 chance in 10^11. I'm sure Paul will do the
full expansion and modelling if anyone wants more precise numbers.

For the chkdsk rename, the probability is much easier to calculate as
it is just the usual birthday expansion (see wikipedia for simple
formula for that). That is what gives 0.5% for 32767 files in a
directory, and 4.8x10^-8 for for 100 files.

Basically it won't happen very often. In each case the probability is
rougly 75x less than it was for the last patch.

 > What if we had a user mode utility that does these short-names
 > renames that a user can optionally run after umount? since it
 > only writes the (random) short-names it's also safe.

While I will defer to John Lanza if you want a more complete legal
view on this, I think it is likely that separating the steps of the
patent between programs within one system is not a safe enough legal
strategy to be used.

Please do keep thinking about it though. There could well be some
simple combination which is legally safe and also technically
completely satisfactory. If you think you have hit on a winner, you
may wish to discuss it with John Lanza in private first though, so it
can be fine tuned before being presented publicly.

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

Hi Pavel,

 > >   - Similarly, there is a small chance that chkdsk on Windows will
 > >     rename one file in a directory if they happen to have the same 11
 > >     byte dummy values. The probability of this happening is
 > >     approximately 80x lower than with the previous patch.
 >
 > The "small chance" seems to be 90% for 30000 files in directory. And
 > no, it is probably not 80x lower. Do the math.

Perhaps you could double check my math?

The number of combinations available with the current patch is
35^6 * 7 * 8 for files (for directories there are more combinations,
but lets ignore that for now).

That comes to 102942875000 combinations.

Now we can do the exponential birthday approximation, which is:

  p = 1.0 - exp(-(n * (n-1)) / (2 * m))

where n is the number of entries in the directory, and m is the total
number of combinations.

That comes to about 0.0052 for 32767 files in a directory
(ie. maximully full), or about 0.5%.

With the previous patch we had 2^30 combinations, which came to 0.393,
or about 39%. So the new patch has about 75x lower chance of a single
collision than the old one.

Similarly for 100 files, the old patch gave a probability of
4.6*10^-6, whereas the new one gives 4.8x10^-8, which is about 96x
lower chance of a single collision.

My '80x' was very rough of course, but its close enough to be a
reasonable rule of thumb I think. What matters here is orders of
magnitude, not precise numbers.

The chance of an actual bluescreen is much lower again, as a
bluescreen happens when two files that have the same 8.3 entry are
accessed in quick succession. Paul did some modelling of that, which
is where the numbers I gave in my last email came from.

I do agree that it would be much better if the chance was zero, but I
also think that the chances of a problem due to a collision are not
really very high, and it may well be lost in the noise of the (rather
common) bluescreens of the fastfat driver on WinXP.

Please do check my maths though. I'll be extremely surprised if you
get anything like 90% as I have run it for days with randomised
testing, and even with the lower chances of the last patch I couldn't
make it happen. I could make it happen by greatly reducing the amount
of randomness in the patch, which is why I know it can happen, but the
probability drops off pretty rapidly with more bits.

Still, my combinatorics is a little rusty, so please correct me if I
have made a mistake.

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

Hi Pavel,

 > Actually, why not having dosfsck creating _matching_ short names for
 > long names? As it only writes short names, it should be safe :-).

As I mentioned to Boaz, what usually matters for claim construction in
patents is the overall system. I'm sure John Lanza would be happy to
run through it with you if you want a more legally detailed answer,
but basically breaking it up within the one system isn't likely to
help us.

Like I mentioned to Boaz though, do keep thinking about it. There may
well be a better solution that nobody has suggested yet. You might
also like to read the file wrapper (availble on the USPTO site) which
shows the discussions between the patent office and the
applicant. That is often a good source of inspiration for patent
workarounds. If you think you've found something then it might be a
good idea to raise it with John Lanza first.

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

[John Lanza]

If I understand the proposal (which I think I do), Tridge is correct.
If a patent prohibits a system from performing steps "A" and "B",
simply separating the steps into separate modules, or utilities, won't
avoid infringement.

I'm happy to answer specific questions, but it might be best to do
that separately from lkml.

johnl

On Tue, Jul 21, 2009 at 9:04 AM, <tridge@...> wrote:

> Hi Boaz,
>
>  > I guess you tried putting a zero at first char and it breaks everybody?
>
> It works with some devices, but with many it doesn't. A space followed
> by a nul works with quite a lot of devices, but not enough (the last
> patch used a space followed by a nul).
>
> I went to a large electronics store and told them I wanted to buy
> devices that didn't work with my computer. They were very helpful, and
> as a result I was able to test a lot of devices. That is what led to
> the design of this patch (plus the feedback from people like Jan and
> his IOneIt MP3 player).
>
>  > I guess (35^6)*8*7 is not that bad
>
> yes, but luckily For the WinXP bluescreen the probability of the crash
> is actually much lower than that figure would give. With the same
> modelling assumptions of WinXP memory slots for 8.3 entries that Paul
> used for the last patch, it comes out as less than a 1 in 10k chance
> for a full directory (ie. 32767 long filenames). For 100 files in a
> directory it is around 1 chance in 10^11. I'm sure Paul will do the
> full expansion and modelling if anyone wants more precise numbers.
>
> For the chkdsk rename, the probability is much easier to calculate as
> it is just the usual birthday expansion (see wikipedia for simple
> formula for that). That is what gives 0.5% for 32767 files in a
> directory, and 4.8x10^-8 for for 100 files.
>
> Basically it won't happen very often. In each case the probability is
> rougly 75x less than it was for the last patch.
>
>  > What if we had a user mode utility that does these short-names
>  > renames that a user can optionally run after umount? since it
>  > only writes the (random) short-names it's also safe.
>
> While I will defer to John Lanza if you want a more complete legal
> view on this, I think it is likely that separating the steps of the
> patent between programs within one system is not a safe enough legal
> strategy to be used.
>
> Please do keep thinking about it though. There could well be some
> simple combination which is legally safe and also technically
> completely satisfactory. If you think you have hit on a winner, you
> may wish to discuss it with John Lanza in private first though, so it
> can be fine tuned before being presented publicly.
>
> Cheers, Tridge
>

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

[John Lanza]

All:

I think the email I just sent applies here, as well.  And I echo
Tridge's sentiments about giving me a shout if you have some idea for
qorkarounds.  I'm here to be a sounding board for you.

johnl

On Tue, Jul 21, 2009 at 9:24 AM, <tridge@...> wrote:

> Hi Pavel,
>
>  > Actually, why not having dosfsck creating _matching_ short names for
>  > long names? As it only writes short names, it should be safe :-).
>
> As I mentioned to Boaz, what usually matters for claim construction in
> patents is the overall system. I'm sure John Lanza would be happy to
> run through it with you if you want a more legally detailed answer,
> but basically breaking it up within the one system isn't likely to
> help us.
>
> Like I mentioned to Boaz though, do keep thinking about it. There may
> well be a better solution that nobody has suggested yet. You might
> also like to read the file wrapper (availble on the USPTO site) which
> shows the discussions between the patent office and the
> applicant. That is often a good source of inspiration for patent
> workarounds. If you think you've found something then it might be a
> good idea to raise it with John Lanza first.
>
> Cheers, Tridge
>

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

[John Lanza]

Resending in plain text..........

On Tue, Jul 21, 2009 at 11:08 AM, John Lanza <jdlanza@...> wrote:

>
> All:
>
> I think the email I just sent applies here, as well.  And I echo
> Tridge's sentiments about giving me a shout if you have some idea for
> qorkarounds.  I'm here to be a sounding board for you.
>
> johnl
>
> On Tue, Jul 21, 2009 at 9:24 AM, <tridge@...> wrote:
> > Hi Pavel,
> >
> >  > Actually, why not having dosfsck creating _matching_ short names for
> >  > long names? As it only writes short names, it should be safe :-).
> >
> > As I mentioned to Boaz, what usually matters for claim construction in
> > patents is the overall system. I'm sure John Lanza would be happy to
> > run through it with you if you want a more legally detailed answer,
> > but basically breaking it up within the one system isn't likely to
> > help us.
> >
> > Like I mentioned to Boaz though, do keep thinking about it. There may
> > well be a better solution that nobody has suggested yet. You might
> > also like to read the file wrapper (availble on the USPTO site) which
> > shows the discussions between the patent office and the
> > applicant. That is often a good source of inspiration for patent
> > workarounds. If you think you've found something then it might be a
> > good idea to raise it with John Lanza first.
> >
> > Cheers, Tridge
> >

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

[John Lanza]

Resending in plain text.......

On Tue, Jul 21, 2009 at 11:06 AM, John Lanza<jdlanza@...> wrote:

> If I understand the proposal (which I think I do), Tridge is correct.
> If a patent prohibits a system from performing steps "A" and "B",
> simply separating the steps into separate modules, or utilities, won't
> avoid infringement.
>
> I'm happy to answer specific questions, but it might be best to do
> that separately from lkml.
>
> johnl
>
> On Tue, Jul 21, 2009 at 9:04 AM, <tridge@...> wrote:
>> Hi Boaz,
>>
>>  > I guess you tried putting a zero at first char and it breaks everybody?
>>
>> It works with some devices, but with many it doesn't. A space followed
>> by a nul works with quite a lot of devices, but not enough (the last
>> patch used a space followed by a nul).
>>
>> I went to a large electronics store and told them I wanted to buy
>> devices that didn't work with my computer. They were very helpful, and
>> as a result I was able to test a lot of devices. That is what led to
>> the design of this patch (plus the feedback from people like Jan and
>> his IOneIt MP3 player).
>>
>>  > I guess (35^6)*8*7 is not that bad
>>
>> yes, but luckily For the WinXP bluescreen the probability of the crash
>> is actually much lower than that figure would give. With the same
>> modelling assumptions of WinXP memory slots for 8.3 entries that Paul
>> used for the last patch, it comes out as less than a 1 in 10k chance
>> for a full directory (ie. 32767 long filenames). For 100 files in a
>> directory it is around 1 chance in 10^11. I'm sure Paul will do the
>> full expansion and modelling if anyone wants more precise numbers.
>>
>> For the chkdsk rename, the probability is much easier to calculate as
>> it is just the usual birthday expansion (see wikipedia for simple
>> formula for that). That is what gives 0.5% for 32767 files in a
>> directory, and 4.8x10^-8 for for 100 files.
>>
>> Basically it won't happen very often. In each case the probability is
>> rougly 75x less than it was for the last patch.
>>
>>  > What if we had a user mode utility that does these short-names
>>  > renames that a user can optionally run after umount? since it
>>  > only writes the (random) short-names it's also safe.
>>
>> While I will defer to John Lanza if you want a more complete legal
>> view on this, I think it is likely that separating the steps of the
>> patent between programs within one system is not a safe enough legal
>> strategy to be used.
>>
>> Please do keep thinking about it though. There could well be some
>> simple combination which is legally safe and also technically
>> completely satisfactory. If you think you have hit on a winner, you
>> may wish to discuss it with John Lanza in private first though, so it
>> can be fine tuned before being presented publicly.
>>
>> Cheers, Tridge
>>
>

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

[Pavel Machek]

Hi!

>  > Actually, why not having dosfsck creating _matching_ short names for
>  > long names? As it only writes short names, it should be safe :-).
>
> As I mentioned to Boaz, what usually matters for claim construction in
> patents is the overall system. I'm sure John Lanza would be happy to
> run through it with you if you want a more legally detailed answer,
> but basically breaking it up within the one system isn't likely to
> help us.

Hehe, or we could create just long names and mark filesystem as
"needing repair" so that Windows fixes it up for us on next mount ;-).
                                                                        Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hi Pavel,

 > Hehe, or we could create just long names and mark filesystem as
 > "needing repair" so that Windows fixes it up for us on next mount ;-).

Adding short names on the windows side would be a valid patent
workaround I believe, but I'm not sure that forcing a chkdsk is a very
useful way to do that. The current windows chkdsk chooses .--N as the
filename, for integer N. It doesn't base the added short name on the
long name.

Paul and I also looked into the option of adding a autorun file of
some sort when files are written on the Linux side, so that a windows
tool adds 8.3 names when the media is inserted. It doesn't turn out to
be very practical however, partly because so many windows systems
don't have auto-run enabled and it looks like MS is disabling it in
future versions. This solution also doesn't work for all the other FAT
devices out there (MP3 players, photo frames etc).

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

[Pavel Machek]

Hi!

>  > >   - Similarly, there is a small chance that chkdsk on Windows will
>  > >     rename one file in a directory if they happen to have the same 11
>  > >     byte dummy values. The probability of this happening is
>  > >     approximately 80x lower than with the previous patch.
>  >
>  > The "small chance" seems to be 90% for 30000 files in directory. And
>  > no, it is probably not 80x lower. Do the math.
>
> Perhaps you could double check my math?
>
> The number of combinations available with the current patch is
> 35^6 * 7 * 8 for files (for directories there are more combinations,
> but lets ignore that for now).
>
> That comes to 102942875000 combinations.
>
> Now we can do the exponential birthday approximation, which is:
>
>   p = 1.0 - exp(-(n * (n-1)) / (2 * m))
>
> where n is the number of entries in the directory, and m is the total
> number of combinations.
>
> That comes to about 0.0052 for 32767 files in a directory
> (ie. maximully full), or about 0.5%.
>
> With the previous patch we had 2^30 combinations, which came to 0.393,
> or about 39%. So the new patch has about 75x lower chance of a single
> collision than the old one.
>
> Similarly for 100 files, the old patch gave a probability of
> 4.6*10^-6, whereas the new one gives 4.8x10^-8, which is about 96x
> lower chance of a single collision.

I guess I should apologize here. I did not do the math. It just seemed
to me that from the paradox of twins, difference should be
greater. Sorry for confusion.
                                                                        Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/