From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Miller" To: mark@codesourcery.com Cc: ak@muc.de, toon@moene.indiv.nluug.nl, law@cygnus.com, jbuck@Synopsys.COM, torvalds@transmeta.com, craig@jcb-sc.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Sat, 05 Jun 1999 11:09:00 -0000 Message-id: <199906051803.LAA15436@pizda.davem.net> References: <18757.928523657@upchuck.cygnus.com> <37591A00.ACE54339@moene.indiv.nluug.nl> <19990605152349.A1923@fred.muc.de> <19990605104107T.mitchell@codesourcery.com> <19990605104107T.mitchell@codesourcery.com> X-SW-Source: 1999-06/msg00201.html From: mark@codesourcery.com Date: Sat, 05 Jun 1999 10:41:07 -0700 Furthermoe, I bet that by now, if all this energy had been spent fixing the code in the kernel, you'd have made good headway on some of the most prominent data structures. Yes, this will be a tedious chore, but it's an easy one: you enclose things in a union, compile, see what doesn't, fix it, and go on. What seems to be ignored are the future maintenance costs incurred by this set of changes to the kernel, as if "do it and get it over right now" is some triviality. Effort has been expended already to make attempts to do this (mentioned here by Andi Klein who did a run at it for the networking), and the findings made there support the non-triviality claim, in Andi's case he tossed the work midstream due to the non-stop overwhelming accumulation of issues. Also some of the datastructures one would need to change are included by userspace applications, especially for some of the networking instances, and thus one would have ABI issues to concern themselves about if they were to go and perform these transformations. Much more is it than a tedious chore. One could certainly create another header file, leave the old one alone with the same name, and use only the new one inside the kernel, but does it make sense to have two copies and maintain them? However the headerfile interface issue is cleanly handled if only the offending code in the kernel is changed (changes thus which are invisible to the user headerfile ABI) to adhere to the proposed gcc cast aliasing behavior. This argument is orthogonal to your proposed possible future maintenance costs gcc might incur due to the implementation of cast aliasing behavior. Later, David S. Miller davem@redhat.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Miller" To: mark@codesourcery.com Cc: ak@muc.de, toon@moene.indiv.nluug.nl, law@cygnus.com, jbuck@Synopsys.COM, torvalds@transmeta.com, craig@jcb-sc.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <199906051803.LAA15436@pizda.davem.net> References: <18757.928523657@upchuck.cygnus.com> <37591A00.ACE54339@moene.indiv.nluug.nl> <19990605152349.A1923@fred.muc.de> <19990605104107T.mitchell@codesourcery.com> X-SW-Source: 1999-06n/msg00201.html Message-ID: <19990630154300.ByGfw8BBX-tIOCkoIaNZ3IRKFFI8weWHdU2PwuJ9G-Q@z> From: mark@codesourcery.com Date: Sat, 05 Jun 1999 10:41:07 -0700 Furthermoe, I bet that by now, if all this energy had been spent fixing the code in the kernel, you'd have made good headway on some of the most prominent data structures. Yes, this will be a tedious chore, but it's an easy one: you enclose things in a union, compile, see what doesn't, fix it, and go on. What seems to be ignored are the future maintenance costs incurred by this set of changes to the kernel, as if "do it and get it over right now" is some triviality. Effort has been expended already to make attempts to do this (mentioned here by Andi Klein who did a run at it for the networking), and the findings made there support the non-triviality claim, in Andi's case he tossed the work midstream due to the non-stop overwhelming accumulation of issues. Also some of the datastructures one would need to change are included by userspace applications, especially for some of the networking instances, and thus one would have ABI issues to concern themselves about if they were to go and perform these transformations. Much more is it than a tedious chore. One could certainly create another header file, leave the old one alone with the same name, and use only the new one inside the kernel, but does it make sense to have two copies and maintain them? However the headerfile interface issue is cleanly handled if only the offending code in the kernel is changed (changes thus which are invisible to the user headerfile ABI) to adhere to the proposed gcc cast aliasing behavior. This argument is orthogonal to your proposed possible future maintenance costs gcc might incur due to the implementation of cast aliasing behavior. Later, David S. Miller davem@redhat.com