Re: [PATCH] utrace: remove exports

[Roland McGrath]

> All the exports in utrace are totally unused, and not really something
> I'd want modules to use anyway :)

Previously you said:

> EXPORT_SYMBOL_GPL(utrace_attach);
> 
> 	There is not modular user of this, so this and the other utrace_
> 	functions should not be exported.  Nor do I think that exporting
> 	such a low-level process control is nessecary a good idea, but
> 	we'll have to evaluate that if patches to add users show up.

If you remove the exports, just throw the whole thing away.
The reason utrace exists is to be used by modules.

It's true that the only users around are some simple test and demo
modules I've done, and some unfinished and experimental work such as
uprobes.  When useful things built on utrace get hashed out and in a
functional state ready for general consumption, then it may be time to
put them in the kernel tree.  (All the work I'm aware of is pretty well
public already, just not in any condition to be submitted.)

There is something of a chicken and egg problem here.  In the current
kernel, most people consider adding or enhancing a user debugging
facility to be intractable.  The intent of utrace is to make
experimenting and developing in this area feasible.  If it's not there,
people can't play with it.  If someone has to have a serious use before
it can be there, it's never going to be easy for anyone to get their
feet wet so they might wind up producing something serious.  

I hope there settles to be one main, nice, new thing at a higher level
with a sane user-level interface, that most everyone wants to use.
Manifestly, I have been taking my sweet time coming up with something
worth talking about so far.  Even when I do produce something like that,
I don't expect everyone to like everything about it that I like.
Someone else might produce something better or sooner or both--but noone
else seems to want to do something else new at the lowest layer.  The
basic utrace interface is about as straightforward in the core kernel
implementation context as it can be while allowing multiple unrelated
higher-level agents to coexist, and cleaning up the interfaces into
machine-dependent code.  The complexities it does have stem from efforts
to make it easier not to write bugs in the higher layers and to make it
harder to write bugs that badly derail user processes or the system
overall.  The hope is to give people a chance to write interesting
things and mitigate some of the most onerous debugging of such things.
Perhaps one day everything anyone wants to do will be based around a
higher-level thing by me or someone else, and the need for the low-level
utrace platform will fall away.  But I tend to think there will always
be some specialized uses for which people want a lower-level base to
work on.  I think of utrace like the block device layer: most people
don't care about that layer, they just want to use a filesystem and
other things above that; but there are always people who want to do some
special thing directly on the lower level, or want to start over
building an entirely different style of filesystem.


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