Re: [osol-code] ddi compliant interface to get u_comm and u_psargs

John Levon wrote: > On Tue, Oct 14, 2008 at 11:28:51AM -0700, Garrett D'Amore wrote: > > >> My code currently does this horribly non-DDI compliant method: >> >> if (ttoproc(curthread)) { >> bcopy(PTOU(ttoproc(curthread))->u_comm, >> c->c_command, sizeof (c->c_command)); >

Re: [osol-code] ddi compliant interface to get u_comm and u_psargs

On Tue, Oct 14, 2008 at 11:28:51AM -0700, Garrett D'Amore wrote: > My code currently does this horribly non-DDI compliant method: > > if (ttoproc(curthread)) { > bcopy(PTOU(ttoproc(curthread))->u_comm, > c->c_command, sizeof (c->c_command)); > bcopy(PTOU(ttoproc(cu

Re: [osol-code] Opensolaris on Sparc

Vikash Tulsiyan wrote: > I am not sure if this is the right forum to discuss this. I want ot know if > opensolaris is already supported on sparc? If not, is their any planned > release for supporting opensolaris on sparc > -- There is not yet an opensolaris release for SPARC. This will likely h

Re: [osol-code] process management

> On Sun, 12 Oct 2008, georgia wrote: > >> Also, >> I would like to know whats the logical order to be studied in the >> code to know all about process management, lwp's, kernel threads and >> stuff.. >> Also i would like to know the scheduling aspect as well. > > I would say that the code is prob

[osol-code] Opensolaris on Sparc

I am not sure if this is the right forum to discuss this. I want ot know if opensolaris is already supported on sparc? If not, is their any planned release for supporting opensolaris on sparc -- This message posted from opensolaris.org ___ opensolaris-c

[osol-code] ddi compliant interface to get u_comm and u_psargs

Right now, I have a driver (the audio subsystem I'm working on) which will ultimately want to be integrated into Nevada. But it wants to access some fields in the uarea of the process that opened the driver initially -- specifically the command and arguments. My code currently does this horribl

Re: [osol-code] process management

On Sun, 12 Oct 2008, Dennis Clarke wrote: > let me dig around ... oh yes .. here it is, under the Solaris Internals > and Practical UNIX Programming : > > Solaris Systems Programming > Prentice Hall Thanks for the plug! -- Rich Teer, SCSA, SCNA, SCSECA CEO, My Online Home Inventory URLs: htt

Re: [osol-code] Attach on non-available instances

> # prtconf | grep 9902,101 > pci9902,101, instance #1 (driver not attached) > > Everything looks good, except that I see another (failing) call to > attach for instance #0 in the log files. Is it possible that you moved the card between PCI slots and there's a stale entry in /etc/

[osol-code] Attach on non-available instances

Hi all, I have written a PCI-device driver according to the informations from SUN's "Device Driver Tutorial" and "Writing Device Drivers". Everything seems fine so far, except that I see calls to the function I specified as "attach" entry point for instances that are not in the machine. In my cas

Re: [osol-code] Mapping device memory

Christian Kaiser wrote: > > Thanks Paul! That helped a lot! > But there is still one minor thing confusing me. Why is ddi_dev_nregs() > returning nregs=6 and not nregs=5? > The brutally simple answer is that the implementation of that function simply takes the length of the 'reg' property and

Re: [osol-code] Mapping device memory

Paul Durrant wrote: > Christian Kaiser wrote: > >> OK... I dont't understand this at all. I did a 32-bit read on all >> BARs. Maybe you can explain me this? >> >> 0x10 0xc830 >> 0x12 0xbeefc830 >> 0x14 0x0 >> 0x16 0x0 >> 0x18 0xd800 >> 0x20 0xd000 >> 0x22 0xbeefd000 >> 0x24 0xcc00

Re: [osol-code] Mapping device memory

Christian Kaiser wrote: > OK... I dont't understand this at all. I did a 32-bit read on all BARs. > Maybe you can explain me this? > > 0x10 0xc830 > 0x12 0xbeefc830 > 0x14 0x0 > 0x16 0x0 > 0x18 0xd800 > 0x20 0xd000 > 0x22 0xbeefd000 > 0x24 0xcc00 > 0x26 0xcc00 > Those are 32-bi