> Peter Memishian wrote:
> > > I was expecting a llib-lrpcsvc file for librpcsvc, but didn't find one.
> >
> > I presume you meant llib-lrpcsvc.ln
>
> well, really he was asking me how to lint a command that uses it, and I
> was surprised not to find the library itself. .ln is the libra
Peter Memishian wrote:
> > I was expecting a llib-lrpcsvc file for librpcsvc, but didn't find one.
>
> I presume you meant llib-lrpcsvc.ln
well, really he was asking me how to lint a command that uses it, and I
was surprised not to find the library itself. .ln is the library source, and it
stan
> I was expecting a llib-lrpcsvc file for librpcsvc, but didn't find one.
I presume you meant llib-lrpcsvc.ln
> Is it just missing or has it not yet been created?
It appears to have not been created.
> If it hasn't been created, what's involved in creating one?
Not much:
1. Create a li
I was expecting a llib-lrpcsvc file for librpcsvc, but didn't find one.
Is it just missing or has it not yet been created?
If it hasn't been created, what's involved in creating one?
Thanks,
-Shawn
This message posted from opensolaris.org
___
opens
This presentation might have at least some helpful background:
http://blogs.sun.com/esaxe/entry/opensolaris_scheduling_and_cpu_management
sched(3HEAD), sched_getparam(3RT), sched_setparam(3RT) define the
sched_param
structure and the interfaces to set/get scheduling parameters (including
micke writes:
> Is it possible Possible to ad a new scheduler to the OpenSolaris kernel?
Yes. It's modular. Existing ones are real-time, time-sharing,
interactive, fair-share, and fixed-priority. These are installed on
the system under /usr/kernel/sched.
> Anyone got some pointers to where I c
Roland Mainz writes:
> Mike Kupfer wrote:
> > I remember running into problems with X applications messing up the ON
> > build, but I don't think I ever figured out which application(s) were
> > running. Do you know?
>
> No... I never hit such a problem... I always worked with "nedit" and
> "xema
On 05/09/07, Joachim Worringen <[EMAIL PROTECTED]> wrote:
>
> Our software stack (which actually consists of 6 kernel modules and much
> userland stuff) uses an internal abstraction layer which makes it
> possible to keep much of the code generic. This is essential to be able
> to support Linux, Wi
Paul Durrant wrote:
>> As I hesitate to use non-public interfaces, I will try the taskq
>> approach. The documentation does mention limits on the execution time of
Typo: does *NOT* mention limits
>> a task within a queue, so it should work.
>>
>
> Yes, I expect taskqs will work for you. As I sai
Hello,
At the bottom of the ON downloads page in the "Now what?" section it is stated:
"If you have decided to build with gcc, be aware that the sources listed above
will not compile with gcc. Read the information in the tools/gcc community get
the appropriate sources and the information you'll
On 05/09/07, Joachim Worringen <[EMAIL PROTECTED]> wrote:
> Thanks Paul, our posts just crossed. Of course there would be other ways
> to implement the functionality we need as you indicated, but the driver
> is rather complex and I don't want to change the design right now, but
> would rather do a
Paul Durrant wrote:
> On 04/09/07, Joachim Worringen <[EMAIL PROTECTED]> wrote:
>> I'm porting a driver from Linux to (Open)Solaris. The driver uses its own
>> threads, which under Linux are created with a simple kernel_thread() call. I
>> don't see such a call under Solaris. A solution could be
>I do of course know about the thread_create() call, but it seems not to
>be a public interface as it does not appear in section 9 of the man
>pages. So, what is the recommended way for a driver to start a new
>kernel thread, or is this not desired?
There are two ways in the kernel to run sc
Joachim Worringen wrote:
> I'm porting a driver from Linux to (Open)Solaris. The driver uses its own
> threads, which under Linux are created with a simple kernel_thread() call.
> I don't see
> such a call under Solaris. A solution could be to create a task queue with
> a single thread, and comm
On 04/09/07, Joachim Worringen <[EMAIL PROTECTED]> wrote:
> I'm porting a driver from Linux to (Open)Solaris. The driver uses its own
> threads, which under Linux are created with a simple kernel_thread() call. I
> don't see such a call under Solaris. A solution could be to create a task
> queue
Is it possible Possible to ad a new scheduler to the OpenSolaris kernel?
Anyone got some pointers to where I can get information?
Im in need of implementing the POSIX SCHED_SPORADIC scheduler under Solaris.
This message posted from opensolaris.org
__
16 matches
Mail list logo
