Peter Teoh wrote:
> On Mon, Aug 24, 2009 at 2:15 AM, James Carlson<carls...@workingcode.com>
> wrote:
>> But I think the real question is why you're attempting to do this ...
>> without knowing that, it's hard to give useful advice.
>>
>
> Thank you everyone for the answer. I rewrote the program (in
> summary) and got into new problem:
[...]
> Notice the mykobj_getsymname() function - which called several kernel
> functions. And noticed that it is not called by any function as
> well. During modloading I got the error:
>
> can't load module: Invalid argument
You might need to enable module load debugging and turn on more syslog
detail to find this, but my guess would be that "mod()" isn't properly
defined in this context.
The reason I'm guessing that is that the only "mod()" I know of in
Solaris is a #define inside $SRC/uts/common/krtld/kobj.c. #defines are
handled by the compiler's preprocessor, and thus don't appear in the
symbol linkage space at all.
> Now therefore the puzzle is how and where to find out what are all the
> symbols which can be recognized and resolved by the kernel loader?
The primary source of information about kernel symbols is the section 9F
man pages. Those are the supported parts of the kernel; the things you
can rely on. If you code to those interfaces, then your module won't
just fall apart the next time you install a patch or upgrade your system.
If you can't abide by the 9F interfaces, then you're basically on your
own. Reading the source code is probably the best long-term answer for
that sort of effort, but occasional well-framed questions on the mailing
lists might help.
Do your customers a favor: don't ship software that's based on
undocumented interfaces. It almost always ends in tears.
> And moreover, kobj_getsymname() is resolved but CANNOT be called
> inside the _init(), as it will lead to system hang. But
> kobj_getsymvalue() can be called inside _init() and output its value
> into dmesg. I wished all these can be made more explicit, or
> automatic, if not at the modloading stage, then a bug check done
> inside kobj_getsymname() to make sure the necessary locks are held, to
> prevent unnecessary system hang. Just my 2cts suggestion :-). Or
> have I missed some other points?
Yes: system design.
When you write a tiny application on your own, broader design questions
are seldom considered and usually don't have much importance. But in a
project as large as OpenSolaris, things are different.
One of the important tasks of anyone working in this sort of environment
is to communicate well with other people at a technical level. An
element of that communication is in clearly delineating what things are
intended for use by others ("I promise that you can use these things
safely, and I'll document them that way"), while reserving other things
for your own use.
That doesn't mean "secrecy." It's not a matter of hiding things or just
being ornery. It's a matter of building a modular and reliable system.
It's always a delicate balance for software designers in determining
what bits others may use (but which are thus nailed down and can't
evolve easily), and what bits are reserved for the implementor and can
change rapidly (but which aren't suitable for use in other contexts,
even if such use would be "interesting").
You can't build a reliable system out of spaghetti. That's why you'll
find that some things are well documented and supported, while other
things are not.
If you find that the things you need are not documented, then you have
at least two choices:
- File an RFE (via bugs.opensolaris.org or defect.opensolaris.org)
asking for a supported way to accomplish your goal. Be prepared to
describe in detail what you're trying to do, and how you'll use the
information you get. Simply saying "please make symbol XXX public"
usually isn't nearly enough. You may also need to discuss alternatives
with the maintainer of the code you're targeting; what you're asking for
might not be feasible.
- Just hack around with the source as you see fit. Know that the sand
may shift under you if you choose this path, and what works this
afternoon might not work tomorrow morning.
As for that one interface, I see no need for the sort of lock checking
that you're describing (and no actual way that it could work reliably in
all cases). The existing consumers of that interface intentionally
don't use the bits when the world is being modified.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
