Hello,
in Linux, whenever system call occurs the kernel will get scheduled.
But how this is explained wrt to QNX as in QNX kernel will never be
scheduled ? ( correct me if i am wrong)
Also if kernel is not scheduled then how the timer etc will be updated ?
kirsh wrote:
Hello,
in Linux, whenever system call occurs the kernel will get scheduled.
But how this is explained wrt to QNX as in QNX kernel will never be
scheduled ? ( correct me if i am wrong)
Also if kernel is not scheduled then how the timer etc will be updated ?
In Linux the kernel is never scheduled (i.e. it implements the scheduler,
and does not need to schedule itself since it is obviously executing if
it is in a position to make a scheduling decision !).
In QNX the kernel is never scheduled either. When a thread calls a kernel
service it is that particular thread that is currently scheduled (not the
kernel).
The kernel updates timers by servicing interrupts (timer interrupts).
This is not generally referred to as scheduling, since timer interrupts
originate completely outside the operating system (which is the frame of
reference).
“Rennie Allen” <rgallen@attbi.com> wrote in message
news:brv8j1$ik7$1@inn.qnx.com…
kirsh wrote:
Hello,in Linux, whenever system call occurs the kernel will get scheduled.
But how this is explained wrt to QNX as in QNX kernel will never be
scheduled ? ( correct me if i am wrong)
Also if kernel is not scheduled then how the timer etc will be updated ?In Linux the kernel is never scheduled (i.e. it implements the scheduler,
and does not need to schedule itself since it is obviously executing if
it is in a position to make a scheduling decision !).
Since drivers, in Linux, are running in the kernel, wouldn’t it be right to
say kernel will get scheduled?
In QNX the kernel is never scheduled either. When a thread calls a kernel
service it is that particular thread that is currently scheduled (not the
kernel).The kernel updates timers by servicing interrupts (timer interrupts).
This is not generally referred to as scheduling, since timer interrupts
originate completely outside the operating system (which is the frame of
reference).
Since drivers, in Linux, are running in the kernel, wouldn’t it be right
to
say kernel will get scheduled?
AFAIK, Linux drivers always run on behalf of calling process, i.e. a process
invokes a syscall, the kernel runs the handler, which calls functions in the
driver.
All in the process timeslice, no rescheduling happens. So I think it
wouldn’t be
fair to say that the kernel gets scheduled. At least this is not what is
usually
understood as scheduling. One exception may be invokation of a tasklet, or
an old-fashioned BH for that matter. In this case the kernel (or the driver)
is running on it’s own behalf - there’s no other pocess scheduled. But this
again
is not what is usually understood as scheduling.
“Dmitri” <ivdal@yahoo.com> wrote in message news:bs4blo$afb$1@inn.qnx.com…
Since drivers, in Linux, are running in the kernel, wouldn’t it be
right
to
say kernel will get scheduled?AFAIK, Linux drivers always run on behalf of calling process, i.e. a
process
invokes a syscall, the kernel runs the handler, which calls functions in
the
driver.
What about when a network driver receives a packet, this isn’t bound to any
process.
What about timer event associated to filesystem flushing its cache? Most
driver I know not only perform work as requested by client but they also
need to do their own bookeeping?
All in the process timeslice, no rescheduling happens. So I think it
wouldn’t be
fair to say that the kernel gets scheduled. At least this is not what is
usually
understood as scheduling. One exception may be invokation of a tasklet, or
an old-fashioned BH for that matter. In this case the kernel (or the
driver)
is running on it’s own behalf - there’s no other pocess scheduled. But
this
again
is not what is usually understood as scheduling.
In article <bs5j6t$6at$1@inn.qnx.com>, postmaster@127.0.0.1 says…
“Dmitri” <> ivdal@yahoo.com> > wrote in message news:bs4blo$afb$> 1@inn.qnx.com> …
Since drivers, in Linux, are running in the kernel, wouldn’t it be
right
to
say kernel will get scheduled?
By whom?
AFAIK, Linux drivers always run on behalf of calling process, i.e. a
process
invokes a syscall, the kernel runs the handler, which calls functions in
the
driver.What about when a network driver receives a packet, this isn’t bound to any
process.
This is called interrupt handling. But if you’re willing to say kernel gets scheduled by interrupts,
CPU exceptions (faults) and system calls - let it be; this is a question of terminology only. Yes
indeed, QNX ukernel, as well as Linux kernel, gets control (takes over the CPU(s)) at some of those
3 points listed above. But I used to think those are interrupts, exceptions and system calls (i.e.
it is not scheduler, but scheduling events) and when something from that list happens the kernel
schedules threads running in system (i.e scheduler is part of the kernel, otherwise the phrase
“kernel gets scheduled” might bring some missunderstanding that scheduler is outside of kernel).
Eduard.
What about timer event associated to filesystem flushing its cache? Most
driver I know not only perform work as requested by client but they also
need to do their own bookeeping?
All in the process timeslice, no rescheduling happens. So I think it
wouldn’t be
fair to say that the kernel gets scheduled. At least this is not what is
usually
understood as scheduling. One exception may be invokation of a tasklet, or
an old-fashioned BH for that matter. In this case the kernel (or the
driver)
is running on it’s own behalf - there’s no other pocess scheduled. But
this
again
is not what is usually understood as scheduling.
\
“ed1k” <ed1k@humber.bay> wrote in message
news:MPG.1a516eb67cf96971989717@inn.qnx.com…
In article <bs5j6t$6at$> 1@inn.qnx.com> >, postmaster@127.0.0.1 says…
“Dmitri” <> ivdal@yahoo.com> > wrote in message
news:bs4blo$afb$> 1@inn.qnx.com> …Since drivers, in Linux, are running in the kernel, wouldn’t it be
right
to
say kernel will get scheduled?By whom?
AFAIK, Linux drivers always run on behalf of calling process, i.e. a
process
invokes a syscall, the kernel runs the handler, which calls functions
in
the
driver.What about when a network driver receives a packet, this isn’t bound to
any
process.This is called interrupt handling.
Not necessarly.
But if you’re willing to say kernel gets scheduled by interrupts,
CPU exceptions (faults) and system calls - let it be; this is a question
of terminology only.
I’m not yet convince it’s terminology only.
Upon receiving an interrupt for network packet for example. Kernels call
interrupt handler and handler is run in the context of the kernel, that’s
the same for QNX and Linux. Then ISR signals some process there is a packet
in the queue. The scheduler will then (under QNX) schedule the network
(that is running in “user” mode) to run. The network driver, will then deal
with the packet and send it to proper protocol manager. Under linux
(correct me if I’m wrong) the scheduler will schedule the network driver,
but the network driver IS PART OF THE KERNEL. Then the network driver will
send it to the protocol manager layer , which is also part of the kernel.
Hence the Linux scheduler will schedule code that is inside the kernel.
In article <bs97do$nsc$1@inn.qnx.com>, postmaster@127.0.0.1 says…
“ed1k” <> ed1k@humber.bay> > wrote in message
news:> MPG.1a516eb67cf96971989717@inn.qnx.com> …
In article <bs5j6t$6at$> 1@inn.qnx.com> >, postmaster@127.0.0.1 says…“Dmitri” <> ivdal@yahoo.com> > wrote in message
news:bs4blo$afb$> 1@inn.qnx.com> …Since drivers, in Linux, are running in the kernel, wouldn’t it be
right
to
say kernel will get scheduled?By whom?
AFAIK, Linux drivers always run on behalf of calling process, i.e. a
process
invokes a syscall, the kernel runs the handler, which calls functions
in
the
driver.What about when a network driver receives a packet, this isn’t bound to
any
process.This is called interrupt handling.
Not necessarly.
I believe you might want to read some good book on interrupt handling in linux. I bet you’ll find a
lot of new concepts and you’ll love monolithic kernels 
But if you’re willing to say kernel gets scheduled by interrupts,
CPU exceptions (faults) and system calls - let it be; this is a question
of terminology only.I’m not yet convince it’s terminology only.
Upon receiving an interrupt for network packet for example. Kernels call
interrupt handler and handler is run in the context of the kernel, that’s
the same for QNX and Linux. Then ISR signals some process there is a packet
in the queue. The scheduler will then (under QNX) schedule the network
(that is running in “user” mode) to run. The network driver, will then deal
with the packet and send it to proper protocol manager. Under linux
(correct me if I’m wrong) the scheduler will schedule the network driver,
but the network driver IS PART OF THE KERNEL. Then the network driver will
send it to the protocol manager layer , which is also part of the kernel.
Hence the Linux scheduler will schedule code that is inside the kernel.
You strained QNX driver model over the linux 
I am not linux guru, but I dare to correct you. In
your assumption the network driver is blocked and waiting message “Hey, there is some packet in
buffer” from ISR. Then network driver looks at the packet and sends message “Hey, this is yours
packet in buffer” to the appropriate protocol manager, which is also blocked and waiting for that
occasion. And both, the network driver and protocol manager, are in the kernel space and are blocked
;o) This is partially true, the truth is they both are in the kernel space. No part of monolithic
linux kernel can be blocked. When linux driver register itself it provide code for system calls
related to device (open/read/close etc.) and hardware specific code (ISR if any, etc.). Kernel code
executing a system call is working in context of an user space process - it operates on behalf of
the calling process and only at this point it is able to access data in the process’s address space.
I.e. if someone calls read() from /dev/device, the kernel will call the function that driver had
been registered beforehand for this occasion, and if there is nothing to read that function can
block waiting for data (or interrupt which will place those data, for example). But it doesn’t mean
the kernel is in blocking state waiting for data, it means the CALLER is blocked.
How exactly network interfaces implemented in linux, beat me, I don’t know. You can take linux
kernel source and take a look, if you’re interested. Theoreticaly there are few ways:
Using of the “slow” interrupt handler to handle all network stuff. I bet this isn’t the case
Linux ISR is usually split in halves. Top-half is fast handler to calm down the hardware and
bottom half implements protocol layer. Old fashion BH or modern tasklet runs in context of ISR, but
scheduled by kernel to run later in a “safer” time (it is different task queue and different
scheduler, AFAIK. It could be some thread inside kernel… in other words kernel doesn’t schedule
itself or some its parts, returning to origin question . It just can have a job to do besides
handling of ISR, exceptions and system calls. If you worked with complex systems in DOS environment
you can think of this ISR technique as setting some global flag and sending end-of-hardware
interrupt to PIC (finish top-half and PIC is ready now to accept new interrupt requests), then some
other part of software cathes that flag and continue ISR processing. This part of software called
kernel, it also could have task queue and when it has nothing to do it runs some processes from task
queue but never put itself in task queue because it is not preemptive and there is no reason for
such a lethal trick
Linux driver can export symbol names. There is kernel symbol table in linux (/proc/ksyms). This
is a way how new driver(module) communicate with kernel to tell it “I’m here - here is my path name
and here is code for my functionality”. So, low level ethernet driver can export some function which
will allow to register protocol manager… probably protocol manager could export name of some
callback and tell network driver “Please call this callback if such packet arrives”
Could be a lot of ways I am unaware of
Merry Christmas!
Eduard