Hakim <ddrv2002@yahoo.ca> wrote:
Hello,
I’m facing some problem in forking from serial resource manager. If I fork
before dev_drvr_register then I get all processes up but if I fork after
dev_drvr_register then all process die during call to fork. How to deal with
dev_drvr_register?
Hm… I know for I/O managers, you can’t create any child processes after
becoming an I/O manager. It makes sense for dev_drvr_register, too. It
does funny things like sharing segments [ugh, evil x86isms]. If you
need to create child/children, you must create them before becoming an
I/O manager.
If you need to create them dynamically, the best structure is to fork()
or spawn*() a child “helper” process, have it Send() you a message, then
Reply() to it with information about what you want spawn()ed [or fork()ed
if you fork()ed it], then it will fork/spawn the new child process and
Send() to you again giving you any information you need (e.g. pid of
child) and saying that it is “ready” to fork() again.
After any entry routine is called for example tto, then if the structure
parameter (struct output_buffer far *obuf) is not updated there then later
when it is updated from a process at that time how to kick the device
manager so that it’ll complete the io and return the write system call to
application?
tti routine is mapped by device manager, if I fork a process before the
mapping then how is possible to map that routine to that process? Simply
mapping far pointer of that routine to that process does not solve the
problem since tti function has reference to other pointers that can not
mapped. This is because tti is in-built in the device manager.
Hm… not sure on how you’re structuring this – but usually only
the Dev.driver talks directly to Dev. If you want multiple fork()ed
children (handling different sockets maybe?) to all talk to Dev, I think
each would have to register directly as a Dev driver.
If, in anyway, you can do it as a single process, it will probably be
cleaner.
If you need multiple processes – I’d suggest only one registered with
Dev, and have all the rest be “slaves” to the main process, with your
own custom message-passing interface between them.
A general question, at what priority level an entry routine for
_IO_OPEN\CLOSE\READ\WRITE\IOCTL is called? I mean what kernel routines can
be safely called at that time? Any list available? Can I call socket
routines at that time? For example as an analogy, in standard serial
resource manager most kernel, socket routines can not be called from tto.
They can’t be called cause tto() might be called at interrupt time
(though, restructuring might fix that, dunno. I haven’t looked at
the QNX4 Dev driver setup for tto(), but I did write a QNX6 sample
Dev driver that restructured things such that tto() would never need
to be called at interrupt time. Much cleaner.) Of course, as others
have noted, you probably don’t have an interrupt at all, so should
be able to make any call you need. The main worry, though, would
be one of making a blocking call that creates a system deadlock –
e.g. Dev calls your tto(), which Send()s to someone which depends on a
Dev device.
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com