OK, let's try cleaning up another nit. Is anyone paying attention?

OK, let's try cleaning up another nit. Is anyone paying attention?

[Eric S. Raymond]

Remove dead CONFIG_BINFMT_JAVA symbol.

--- arch/cris/config.in	2001/04/18 14:18:58	1.1
+++ arch/cris/config.in	2001/04/18 14:19:11
@@ -18,9 +18,6 @@
 bool 'System V IPC' CONFIG_SYSVIPC
 
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
-if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-  tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
-fi
 
 bool 'Use kernel gdb debugger' CONFIG_KGDB
 
--- arch/cris/defconfig	2001/04/18 14:31:34	1.1
+++ arch/cris/defconfig	2001/04/18 14:31:39
@@ -14,7 +14,6 @@
 CONFIG_NET=y
 CONFIG_SYSVIPC=y
 CONFIG_BINFMT_ELF=y
-# CONFIG_BINFMT_JAVA is not set
 # CONFIG_KGDB is not set
 # CONFIG_ETRAX_WATCHDOG is not set
 CONFIG_USE_SERIAL_CONSOLE=y
--- arch/parisc/config.in	2001/04/18 14:18:08	1.1
+++ arch/parisc/config.in	2001/04/18 14:18:28
@@ -66,9 +66,6 @@
 tristate 'Kernel support for SOM binaries' CONFIG_BINFMT_SOM
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
-if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-  tristate 'Kernel support for JAVA binaries (obsolete)' CONFIG_BINFMT_JAVA
-fi
 
 endmenu
 
--- arch/parisc/defconfig	2001/04/18 14:18:49	1.1
+++ arch/parisc/defconfig	2001/04/18 14:18:53
@@ -40,7 +40,6 @@
 CONFIG_BINFMT_SOM=y
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BINFMT_JAVA is not set
 
 #
 # Parallel port support

End of diffs.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
        -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
            referred to in the Second Amendment to the Constitution.

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Matthew Wilcox]

On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
> Remove dead CONFIG_BINFMT_JAVA symbol.

Please don't do this, it just makes merging our patches with Linus harder.
This has already been done in our tree since Feb 1.  In fact, please
don't touch anything in the tree which is PA specific; we have a large
arch update pending.

http://puffin.external.hp.com/cvs/linux/arch/parisc/config.in?log=y

shows the current state of our config.in, if you're curious.  If you
have any changes you want to make, don't hesitate to coordinate with us
by mailing parisc-linux@parisc-linux.org.

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Eric S. Raymond]

Matthew Wilcox <willy@ldl.fc.hp.com>:
> On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
> > Remove dead CONFIG_BINFMT_JAVA symbol.
> 
> Please don't do this, it just makes merging our patches with Linus harder.

Bother.  I've now heard "don't touch that tree!" from you and the ARM
folks.  I'm trying to be a good neighbor, here, but there is some
cleanup I want to do that crosses port boundaries.  (None of this is CML2,
BTW; I'm now addressing problems that are common to CML1 as well.)

What is the right procedure for doing changes like this?  Is "don't
touch that tree" a permanent condition, or am I going to get a chance
to clean up the global CONFIG_ namespace after your next merge-down?

Could I ask you to audit your tree and change the prefix on any 
CONFIG_ symbols that are private over there?  This would make life 
easier for my auditing tools (kxref and Stephen Cole's ach script).

That's the main thing I'm after right now -- I want to cut down on
the false positives in my orphaned-symbol reports so that the actual
bugs will stand out.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety."
	-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Matthew Wilcox]

On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
> What is the right procedure for doing changes like this?  Is "don't
> touch that tree" a permanent condition, or am I going to get a chance
> to clean up the global CONFIG_ namespace after your next merge-down?

Our current status is that we've got a patch with Alan that's been sitting
in his tree for a while (things got trickier than he expected and he
hasn't been able to merge that upstream to Linus yet).  Meanwhile we've
carried on development as normal.  So even after the patches in Alan's
tree land, we've still got a fair hunk of changes to go in.

My preference would be for you to fetch our tree 

cvs -d :pserver:anonymous@puffin.external.hp.com:/home/cvs/parisc login
[no password]

cvs -d :pserver:anonymous@puffin.external.hp.com:/home/cvs/parisc co linux

and submit patches to us, which will get to Linus in the fullness of time.
I'm aware this might not be terribly satisfactory for you, but we're
doing our best not to lose our way amid the churn of development right
now and having patches which haven't followed a progression through
us makes that significantly harder.

> Could I ask you to audit your tree and change the prefix on any 
> CONFIG_ symbols that are private over there?  This would make life 
> easier for my auditing tools (kxref and Stephen Cole's ach script).

I don't think we have any of those.  We certainly have symbols which are
defined for symmetry and may not actually be used yet (CONFIG_PA11 might not
be, perhaps).  But that's what happens when you're developing software :-)

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[james rich]

On Thu, 19 Apr 2001, Matthew Wilcox wrote:

> On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
> > What is the right procedure for doing changes like this?  Is "don't
> > touch that tree" a permanent condition, or am I going to get a chance
> > to clean up the global CONFIG_ namespace after your next merge-down?
> 

[snip]

> My preference would be for you to fetch our tree 

> and submit patches to us, which will get to Linus in the fullness of time.

Truly this is not meant to be negative - don't take it as such.

Doesn't this seem a little like the problems occurring with lvm right now?
A separate tree maintained with the maintainers not wanting others
submitting patches that conflict with their particular tree?  It seems
that any project should be able to submit any patch against The One True
Tree: Linus' tree.

James Rich
james.rich@m.cc.utah.edu

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Matthew Wilcox]

On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
> Doesn't this seem a little like the problems occurring with lvm right now?
> A separate tree maintained with the maintainers not wanting others
> submitting patches that conflict with their particular tree?  It seems
> that any project should be able to submit any patch against The One True
> Tree: Linus' tree.

every single architecture has their own development tree.  the pa project
has not been running as long as the other ports, and has a large amount of
development going on.  i count 28 commits for april (so far), 75 commits
for march, 187 for february and 112 for january (to the kernel tree, other
parts of the port also have commit messages).  linus would go insane if
we sent him every single one of those patches individually.  and we'd
go insane trying to keep up with what he'd taken and what he'd dropped.

until you've actually tried doing this, please don't attempt to criticise.

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Albert D. Cahalan]

Matthew Wilcox writes:
> On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:

>> Doesn't this seem a little like the problems occurring with lvm right now?
>> A separate tree maintained with the maintainers not wanting others
>> submitting patches that conflict with their particular tree?  It seems
>> that any project should be able to submit any patch against The One True
>> Tree: Linus' tree.
>
> every single architecture has their own development tree.

This sucks for users of that architecture. Also, though not
applicable to PA-RISC, it sucks for sub-architecture porters.
(by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.)

It's hard enough deciding between Linus and Alan. I'm not at all
happy trying to pick through obscure CVS and BitKeeper trees that
might not be up-to-data with the latest mainstream bug fixes.

> the pa project
> has not been running as long as the other ports, and has a large amount of
> development going on.  i count 28 commits for april (so far), 75 commits
> for march, 187 for february and 112 for january (to the kernel tree, other
> parts of the port also have commit messages).  linus would go insane if
> we sent him every single one of those patches individually.  and we'd
> go insane trying to keep up with what he'd taken and what he'd dropped.
> 
> until you've actually tried doing this, please don't attempt to criticise.

Have _you_ tried? If I recall correctly, Linus spoke out against the
PowerPC people doing the exact same thing. So unless you get told to
quit annoying him with patches, sending them is the safe bet.

Well here we go. It's about IrDA though, not PowerPC. Read it!
http://lwn.net/2000/1109/a/lt-IrDA.php3

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Rik van Riel]

On Fri, 20 Apr 2001, Albert D. Cahalan wrote:

> This sucks for users of that architecture. Also, though not
> applicable to PA-RISC, it sucks for sub-architecture porters.
> (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.)

As you said it so eloquently a few paragraphs down:

	"send patches!"

cheers,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[David Woodhouse]

james.rich@m.cc.utah.edu said:
>  Doesn't this seem a little like the problems occurring with lvm right
> now? A separate tree maintained with the maintainers not wanting
> others submitting patches that conflict with their particular tree?
> It seems that any project should be able to submit any patch against
> The One True Tree: Linus' tree. 

Of course they can. Linus does apply them too. People are asking nicely 
that ESR not do so in this case, because merges are being planned. 

The contents of drivers/mtd/ are in the same situation. For some reason, I
felt it inappropriate to give every patch at every stage of development to
Linus for inclusion in the 2.4.0-test and 2.4.[123] kernels. Now I'm vaguely
happy with it all and it's stable, I'm working on cleaning up some of the 
cosmetics and breaking it up into digestible patches.

Doing primary development in CVS seems to work OK for me, and allows me to 
continue development without destabilising the One True Tree. During such 
times, it's useful to have a branch for the code which is in the One True 
Tree, so urgent fixes can be merged, and the diff against the One True Tree 
after each release has something to diff against to catch patches where 
people didn't even bother to Cc the maintainer.

I believe people were _told_ to hold off until 2.4.5-ish, or when the tree
became stable. Violent imagery was used to reinforce this instruction.
That being the case, how about holding the config changes back until after 
everyone else who's been waiting has merged their pending changes?

--
dwmw2

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Eric S. Raymond]

Matthew Wilcox <willy@ldl.fc.hp.com>:
> > Could I ask you to audit your tree and change the prefix on any 
> > CONFIG_ symbols that are private over there?  This would make life 
> > easier for my auditing tools (kxref and Stephen Cole's ach script).
> 
> I don't think we have any of those.  We certainly have symbols which are
> defined for symmetry and may not actually be used yet (CONFIG_PA11 might not
> be, perhaps).  But that's what happens when you're developing software :-)

Here's what I have for you guys:

CONFIG_BINFMT_JAVA: arch/parisc/config.in arch/parisc/defconfig arch/cris/config.in arch/cris/defconfig

You've already gotten rid of that one.

CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig

Not used in code anywhere.  Can you get rid of this one?

CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c

Would you please take these out of the CONFIG_ namespace?  Changing the 
prefix to CONFIGURE would do nicely.

CONFIG_GENRTC: arch/parisc/defconfig

This is a typo for GEN_RTC.  Please fix it or get rid of it.

CONFIG_HIL: arch/parisc/defconfig

Looks like an orphan.  Can you get rid of it?

CONFIG_GSC: arch/parisc/config.in arch/parisc/defconfig
CONFIG_GSC_DINO: arch/parisc/config.in arch/parisc/defconfig
CONFIG_GSC_LASI: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/led.c
CONFIG_GSC_PS2: arch/parisc/config.in arch/parisc/defconfig
CONFIG_IODC_CONSOLE: arch/parisc/config.in arch/parisc/kernel/setup.c
CONFIG_IOMMU_CCIO: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile
CONFIG_IOMMU_SBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile
CONFIG_IOSAPIC: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile
CONFIG_KWDB: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/entry.S arch/parisc/kernel/traps.c arch/parisc/mm/init.c
CONFIG_LASI_82596: arch/parisc/config.in arch/parisc/defconfig
CONFIG_PARPORT_GSC: drivers/parport/Makefile arch/parisc/config.in arch/parisc/defconfig
CONFIG_PCI_LBA: arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/Makefile
CONFIG_SCSI_LASI: arch/parisc/config.in arch/parisc/defconfig
CONFIG_SCSI_ZALON: arch/parisc/config.in arch/parisc/defconfig
CONFIG_STI_CONSOLE: arch/parisc/Makefile arch/parisc/config.in arch/parisc/defconfig arch/parisc/kernel/setup.c arch/parisc/mm/init.c

Looks like these need Configure.help entries.

CONFIG_SERIAL_GSC: drivers/char/serial.c arch/parisc/defconfig

That reference pattern looks kind of weird.  Is this a bug?

If you could clean these up, that's everything I need from the parisc tree.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

(Those) who are trying to read the Second Amendment out of the Constitution by
claiming it's not an individual right (are) courting disaster by encouraging
others to use the same means to eliminate portions of the Constitution they
don't like.
	-- Alan Dershowitz, Harvard Law School

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Matthew Wilcox]

On Fri, Apr 20, 2001 at 03:47:43PM -0400, Eric S. Raymond wrote:
> CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig
> 
> Not used in code anywhere.  Can you get rid of this one?

Code not merged yet.

> CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
> CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c
> 
> Would you please take these out of the CONFIG_ namespace?  Changing the 
> prefix to CONFIGURE would do nicely.

Grant?  This is your code.

> CONFIG_GENRTC: arch/parisc/defconfig
> 
> This is a typo for GEN_RTC.  Please fix it or get rid of it.

in our tree it's in drivers/char/Makefile:

obj-$(CONFIG_GENRTC) += genrtc.o

this code was written by Sam Creasey as part of the sun3 port, and he
schlepped it into our tree too.  we have no GEN_RTC in our tree.

> CONFIG_HIL: arch/parisc/defconfig
> 
> Looks like an orphan.  Can you get rid of it?

code not yet merged.

> CONFIG_SERIAL_GSC: drivers/char/serial.c arch/parisc/defconfig
> 
> That reference pattern looks kind of weird.  Is this a bug?

it's old and needs to die properly.  i haven't had time to fix that yet.

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Eric S. Raymond]

Matthew Wilcox <willy@ldl.fc.hp.com>:
> Code not merged yet.
    :
> it's old and needs to die properly.  i haven't had time to fix that yet.

Thanks for the information.  Actually the parisc tree is one of the ones
that leaks the fewest of these symbols... 
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Ideology, politics and journalism, which luxuriate in failure, are
impotent in the face of hope and joy.
	-- P. J. O'Rourke

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Alan Cox]

> CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig
> Not used in code anywhere.  Can you get rid of this one?

Its used in the parisc tree as are most of the others you see. You probably want
to simply skip processing arch/parisc

Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Alan Cox]

> What is the right procedure for doing changes like this?  Is "don't
> touch that tree" a permanent condition, or am I going to get a chance
> to clean up the global CONFIG_ namespace after your next merge-down?

Feeding arch related stuff to the architecture maintainers.

> That's the main thing I'm after right now -- I want to cut down on
> the false positives in my orphaned-symbol reports so that the actual
> bugs will stand out.

Teach it to read a 'symbolstoignore' file.

Part of the problem you are hitting right now is that most architectures are
not yet fully in sync with 2.4 nor likely to all be for another few iterations.

Re: OK, let's try cleaning up another nit. Is anyone paying attention?

[Riley Williams]

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

Hi Alan, Eric.

>> That's the main thing I'm after right now -- I want to cut down on
>> the false positives in my orphaned-symbol reports so that the
actual
>> bugs will stand out.

> Teach it to read a 'symbolstoignore' file.
>
> Part of the problem you are hitting right now is that most
architectures are
> not yet fully in sync with 2.4 nor likely to all be for another few
iterations.

Not sure if it's relevant, but, I've enclosed (1) a bash script that
produces an analysis of the CONFIG_ variables in a specified Linux
kernel source tree, and (2) the results from running that on the 2.4.5
tree. It analyses all files matching '*.?' and '[Cc]onfig.in' in the
specified tree, and reports on the results by summarising both how
many times each CONFIG_* variable is used total, which files it is
used in, and how many times it is used in each file.

Best wishes from Riley.


[-- Attachment #2: allgrep.gz --]
[-- Type: application/octet-stream, Size: 477 bytes --]