Building on case-insensitive filesystems

Building on case-insensitive filesystems

[Dan Kegel]

$ ls {include/linux/netfilter_ipv4,net/ipv4/netfilter}/*.{h,c}
shows eight pairs of files whose names differ only in case.
For example:
$ more include/linux/netfilter_ipv4/ipt_{mark,MARK}.h
::::::::::::::
include/linux/netfilter_ipv4/ipt_mark.h
::::::::::::::
#ifndef _IPT_MARK_H
#define _IPT_MARK_H

struct ipt_mark_info {
     unsigned long mark, mask;
     u_int8_t invert;
};

#endif /*_IPT_MARK_H*/

::::::::::::::
include/linux/netfilter_ipv4/ipt_MARK.h
::::::::::::::
#ifndef _IPT_MARK_H_target
#define _IPT_MARK_H_target

struct ipt_mark_target_info {
         unsigned long mark;
};

#endif /*_IPT_MARK_H_target*/

Seems like ipt_mark_target.h might be a better name for
that latter file.  That would let developers who have
MacOSX or Windows laptops successfully unpack the
Linux source tree on their computers' case-insensitive filesystems.

I maintain http://kegel.com/crosstool, which is a script
that builds arbitrary combinations of gcc + {g,uc}libc + binutils + linux headers + target.
As a check on the resulting cross toolchains, I try building
a Linux kernel.  This works great in general, but on
operating systems with case-insensitive filesystems
(MacOSX, Cygwin), building the linux kernel understandably fails on these files.

Here's the patch I've been using to do a rename and fix Makefiles to match:
   http://www.kegel.com/crosstool/linux-2.6.8-netfilter-case-insensitive.patch
It renames the uppercase variants to add a _u suffix, but I would
gladly rework the patch to use a nicer suffix (like _target) if
that would help make the rename happen.

This is part of a larger effort to make life easier for
embedded Linux developers who are stuck developing on Windows
or Mac systems; see discussion at
http://marc.theaimsgroup.com/?l=linux-kernel&m=109713211417106&w=2
(Summary: Sam Ravnborg is helping; Russel King is skeptical.)
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

Re: Building on case-insensitive filesystems

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

Hi Dan :)

On Sat, Oct 16, 2004 at 12:35:43PM -0700, Dan Kegel wrote:
> Seems like ipt_mark_target.h might be a better name for
> that latter file.  That would let developers who have
> MacOSX or Windows laptops successfully unpack the
> Linux source tree on their computers' case-insensitive filesystems.

This has been discussed on the list before, the general result was IIRC
that we don't really care, sorry.

Next time somebody comes along and says well, your more-than-8.3chars
long filenames won't work on my DOS system.  

iptables fundamentally relies on the destinction:

lowercase == match module
uppercase == target module

You can't just fix this by renaming kernel source files.

If I read your patch correctly, the resulting modules will have
different names.  This will break auto-loading of match and target
extensions, and it will break userspace compatibility with the userspace
iptables program.

Also, the userspace iptables program has the same assumption, so without
changing the whole chain
	- kernel file names
	- module autoloading
	- userspace filenames
	- userspace plugin autoloading
it will not work.

Also, imagine what happens if someone tries to run an old userspace
program and a new kernel or vice versa.  If we ever adopt a renaming
scheme, it would have to work both forward and backwards compatible, we
can't just change this within a stable kernel series.

> Here's the patch I've been using to do a rename and fix Makefiles to match:
 
> This is part of a larger effort to make life easier for
> embedded Linux developers who are stuck developing on Windows
> or Mac systems; see discussion at

You should actually start an opposite effort:  Make it harder for them,
so it is enough pain to switch to a linux development system.  Please
note, this is my personal opinion - not to be conflicted with the
technical reasons given above.

> - Dan

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Building on case-insensitive filesystems

[Dan Kegel]

Harald Welte wrote:
>>Seems like ipt_mark_target.h might be a better name for
>>that latter file.  That would let developers who have
>>MacOSX or Windows laptops successfully unpack the
>>Linux source tree on their computers' case-insensitive filesystems.
> 
> 
> This has been discussed on the list before, the general result was IIRC
> that we don't really care, sorry.

Ah, well, crossdevelopers are used to encountering
indifference now and then from mainstream developers, so that's
not terribly surprising.

> Next time somebody comes along and says well, your more-than-8.3chars
> long filenames won't work on my DOS system.  

Let's see if we can distinguish between the two problems.  I know,
how 'bout this: it's reasonable to be expected to support
developer workstation filesystems which have a greater than 20% market share.
By that measure, it's reasonable to expect support for developing on
case-insensitive filesystems, but not on 8.3 char filesystems.
Hey, I did it!  (cue confetti)

> iptables fundamentally relies on the destinction:
> 
> lowercase == match module
> uppercase == target module
> 
> You can't just fix this by renaming kernel source files.
> 
> If I read your patch correctly, the resulting modules will have
> different names.  This will break auto-loading of match and target
> extensions, and it will break userspace compatibility with the userspace
> iptables program.
> 
> Also, the userspace iptables program has the same assumption, so without
> changing the whole chain
> 	- kernel file names
> 	- module autoloading
> 	- userspace filenames
> 	- userspace plugin autoloading
> it will not work.
> 
> Also, imagine what happens if someone tries to run an old userspace
> program and a new kernel or vice versa.  If we ever adopt a renaming
> scheme, it would have to work both forward and backwards compatible, we
> can't just change this within a stable kernel series.

Thanks for the summary of the technical issues.
I'm sure somebody sufficiently motivated could solve them
in a reasonable way.  I'll leave this for later -- I'm only
verifying gcc/glibc builds, so I don't need it -- but maybe
somebody else will come up with the right fix.

>>This is part of a larger effort to make life easier for
>>embedded Linux developers who are stuck developing on Windows
>>or Mac systems; see discussion at
> 
> You should actually start an opposite effort:  Make it harder for them,
> so it is enough pain to switch to a linux development system.  Please
> note, this is my personal opinion - not to be conflicted with the
> technical reasons given above.

Your helpful attitude is greatly appreciated.
- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html