On Fri, Aug 1, 2008 at 1:34 AM, Dan Mick <[EMAIL PROTECTED]> wrote:
>
>
> Not surprising, since that's not the message you posted:
>
> Jul 31 16:15:55 nemesis pci_autoconfig: [ID 516285 kern.warning]
> WARNING: failed to program mem space [0/31/3] [EMAIL PROTECTED] length 0x100
Hi !
Yeah I know,
Rob (and everyone else):
Removal of "private and undocumented headers" from the delivered
distribution will never prevent you from having access to those bits
that are part of the source product.
Please don't confuse *source* code with the delivered headers used for
"normal" software engineeri
James Carlson wrote:
>
> Private, undocumented interfaces installed by default in Solaris
> represent both unnecessary clutter, and an attractive nuisance for the
> unwary. With some 14 megabytes in 2054 header files under
> /usr/include, there's quite a bit of both in s10.
_IF_ some code _actua
Patrick Ale wrote:
> On Thu, Jul 31, 2008 at 11:27 PM, Patrick Ale <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> Not sure if this is the right list, if not, sorry :)
>>
> I
>> am downloading the onnv-gate source now to see on what function/symbol
>> I should set a breakpoint to provide you with the s
On Thu, Jul 31, 2008 at 11:27 PM, Patrick Ale <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Not sure if this is the right list, if not, sorry :)
>
I
> am downloading the onnv-gate source now to see on what function/symbol
> I should set a breakpoint to provide you with the stack trace (also a
> learning
Joachim Worringen wrote:
>Greetings,
>
>I need to get the addresses and network masks of all IP interfaces from
>within my driver (thus, within the kernel). This principally works with
>the code shown below.
>
>
If you look in , you'll find these:
extern int net_getlifaddr(net_data_t, phy_if
Hello,
Not sure if this is the right list, if not, sorry :)
When booting my Aspire 8920 (x64) laptop I receive the following error
upon kernel boot
Jul 31 16:15:55 nemesis pci_autoconfig: [ID 516285 kern.warning]
WARNING: failed to program mem space [0/31/3] [EMAIL PROTECTED] length 0x100
I am
Joachim Worringen writes:
> Peter Memishian wrote:
> > > Suggestion on existing solutions still welcome...
> >
> > Can you elaborate on why you need to do this within the kernel?
> >
>
> Good point. I'm porting a driver (socket module) from Linux to Solaris.
>
> The rationale to do it within t
Peter Memishian writes:
>
> > Suggestion on existing solutions still welcome...
>
> Can you elaborate on why you need to do this within the kernel?
In addition to that (which I think is a pretty good question), I can
answer the bit about locks: there aren't any.
The SIOCGLIFNUM interface is So
Peter Memishian wrote:
> > Suggestion on existing solutions still welcome...
>
> Can you elaborate on why you need to do this within the kernel?
>
Good point. I'm porting a driver (socket module) from Linux to Solaris.
The rationale to do it within the driver is that we need to know if
interf
> Suggestion on existing solutions still welcome...
Can you elaborate on why you need to do this within the kernel?
--
meem
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-co
Joachim Worringen wrote:
> Joachim Worringen wrote:
>> Greetings,
>>
>> I need to get the addresses and network masks of all IP interfaces from
>> within my driver (thus, within the kernel). This principally works with
>> the code shown below.
>
> Sorry, I was wrong (did not test the code I past
Joachim Worringen wrote:
> Greetings,
>
> I need to get the addresses and network masks of all IP interfaces from
> within my driver (thus, within the kernel). This principally works with
> the code shown below.
Sorry, I was wrong (did not test the code I pasted below, but other
code); the cod
Greetings,
I need to get the addresses and network masks of all IP interfaces from
within my driver (thus, within the kernel). This principally works with
the code shown below.
However, I wonder how I can avoid the race between the two ioctl's I'm
doing. Which lock must I use?
Other comments
On Thu, Jul 31, 2008 at 3:27 PM, Jan Pechanec <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Jul 2008, Darren J Moffat wrote:
>
>>> I am building debug version of one of the shared libraries in ON (I
>>> need to run it through dbx), but it seems to still lack debug info.
>>> Am I missing something obviou
On Thu, 31 Jul 2008, Darren J Moffat wrote:
>> I am building debug version of one of the shared libraries in ON (I
>> need to run it through dbx), but it seems to still lack debug info.
>> Am I missing something obvious here, or does it require some special
>> make procedure to be used ?
>> I am
On Thu, Jul 31, 2008 at 3:19 PM, Darren J Moffat
<[EMAIL PROTECTED]> wrote:
> Cyril Plisko wrote:
>>
>> Hello !
>>
>> I am building debug version of one of the shared libraries in ON (I
>> need to run it through dbx), but it seems to still lack debug info.
>> Am I missing something obvious here, o
Cyril Plisko wrote:
> Hello !
>
> I am building debug version of one of the shared libraries in ON (I
> need to run it through dbx), but it seems to still lack debug info.
> Am I missing something obvious here, or does it require some special
> make procedure to be used ?
> I am able to debug it
Hello !
I am building debug version of one of the shared libraries in ON (I
need to run it through dbx), but it seems to still lack debug info.
Am I missing something obvious here, or does it require some special
make procedure to be used ?
I am able to debug it if I compile every source myself a
19 matches
Mail list logo
