Agreed - we plan on using documented interfaces. I'll puruse the driver tutorial and writer documents. My main issue at the moment is the specifics of getting things compiled and linked for i386 32/64. If that is addressed in the documents, then I should have what I need.
Thanks for the responses. Mark > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jason King > Sent: 2010-01-18 15:30 > To: Milan Jurik > Cc: Mark Maule; [email protected] > Subject: Re: [osol-discuss] building standalone modules > > I would just add, if the module is not something that is going to be > added to the ON source tree, to be sure to stick to the documented > DDI. Using functions outside of that is at a 'do so at your own risk' > type thing -- they aren't guaranteed to be there, work the same way, > etc. in future updates (that's part of the reason for classification > of interfaces in Solaris -- is to capture that intent for the benefit > of those that aren't the kernel engineers :P). > > As such, it also tends to (mostly deliberately) be a bigger pain to > get the necessary environment built that will include the definitions > of things not in the DDI. > > > On Mon, Jan 18, 2010 at 3:18 PM, Milan Jurik <[email protected]> wrote: > > Mark, > > > > Mark Maule píše v po 18. 01. 2010 v 11:58 -0800: > >> Thanks Milan: > >> > >> The things we are working on would remain private. I would plan on > generating them using an opensolaris machine running a ONNV installation > close to what we will be running on the product. Eventually, would like > to be able to cross compile them from a different machine, possibly > running Linux. > >> > > > > OK, then it is your decision how to make your life easy :-) The > > cross-compile enviroment can be small challenge for kernel modules, as > > every good cross-compile enviroment. But I am not expert. > > > >> As far as cc/ld flags necessary for generating the kernel modules, is > that formally documented somewhere, or do I just look to ONNV modules for > examples? > >> > > > > I would start with simple "Device Driver Tutorial" and then "Writing > > Device Drivers" on docs.sun.com > > > > For non-device drivers modules I can recommend Solaris Internals, book > > and/or very good training. > > > > Best regards, > > > > Milan > > > >> thanks > >> Mark > >> > >> > -----Original Message----- > >> > From: [email protected] [mailto:[email protected]] > >> > Sent: 2010-01-18 13:09 > >> > To: Mark Maule > >> > Cc: [email protected] > >> > Subject: Re: [osol-discuss] building standalone modules > >> > > >> > Hi Mark, > >> > > >> > Mark Maule píše v so 16. 01. 2010 v 14:12 -0800: > >> > > Not sure if this is the correct forum, so starting here: > >> > > > >> > > >> > It depends of what you really need. > >> > > >> > > We are building a system based on opensolaris, and will be adding > our > >> > > own kernel modules. What is the precedent for building vendor- > supplied > >> > > modules? Are they generally incorporated under the os-nv src tree? > My > >> > > preference would be to build them outside the os-nv tree in order > to > >> > > avoid "polluting" the tree with vendor-specific module (and > command) > >> > > code. > >> > > > >> > > >> > If you plan to keep those modules private for your company, then you > can > >> > keep them in nested workspace everywhere you want. If you plan to > >> > integrate them later to upstream os-nv, follow os-nv tree structure, > >> > there are several examples of modules comming from device vendors > (e.g. > >> > Intel) in os-nv gate. As for nested workspaces, Mercurial ignores > >> > subdirectories which are not maintained by it, so you can include > them > >> > everywhere inside tree on build machines. > >> > > >> > Best regards, > >> > > >> > Milan > >> > > > > > > _______________________________________________ > > opensolaris-discuss mailing list > > [email protected] _______________________________________________ opensolaris-discuss mailing list [email protected]
