On Thu, Aug 27, 2009 at 7:09 PM, James Carlson<carls...@workingcode.com> wrote:
> 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>
>
I am a newbie in Opensolaris (but not Sun/Sparc). And wow!!! These
are a good load of lessons to learn for me.....thank you for the time
spent James!!!! Appreciate very much!!!
--
Regards,
Peter Teoh
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
