Re: Building on case-insensitive filesystems

[Dan Kegel <dank@kegel.com>]

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