question about MINIX3 terminal driver

In driver/tty/tty.c, before enter main loop, it call printf("\n");
This uses printf() routine in libsysutil, which in turn call to
kputc(), finally send a message to tty driver
to print the message.
My question is the method kputc() used is sendrec(), which would block
tty driver ifself(since tty driver
is not ready to receive.), and removed from ready queue.
This means TTY driver have no chance to run again, and other routines
using TTY serives
would block subsequently.

But MINIX3 runs well. I must ignore something...
Any helps welcomed.

Regard
Sheng-yu

Minix 3 has completely changed the structures into "true michro kernel"

It does not call sendrec() to the driver since it would cause a
deadlock as you know.
Therefore Minix 3 uses a notification mecanism to the dirver
Please refer to the module kputc() in Minix 3

I hope it helps

Tyson M Kim

Thanks for your help...

But as I know, tty driver is linked with libsysutil.a (I didn't see any
definition
of printf in tty driver). This version of printf using sendrec()
finally.

I know in-kernel procedure kprintf() in kernel/utility.c using
notification mechanism,
so it's safe to print something before tty driver is fully initialized
and
ready to receive. But. it seems all drivers and servers using printf in
libsysutil.

Any suggestion futher?

[email]ma777x@hotmail.com[/email] schrieb:
[color=blue]
> Minix 3 has completely changed the structures into "true michro kernel"
>
> It does not call sendrec() to the driver since it would cause a
> deadlock as you know.
> Therefore Minix 3 uses a notification mecanism to the dirver
> Please refer to the module kputc() in Minix 3
>
> I hope it helps
>
> Tyson M Kim[/color]

All,
[color=blue]
> I know in-kernel procedure kprintf() in kernel/utility.c using
> notification mechanism,
> so it's safe to print something before tty driver is fully initialized
> and
> ready to receive. But. it seems all drivers and servers using printf in
> libsysutil.
>
> Any suggestion futher?[/color]

tty redefines its own kputc().

=Ben

Oh....I got the point.
Thanks!!

Ben Gras schrieb:
[color=blue]
> All,
>[color=green]
> > I know in-kernel procedure kprintf() in kernel/utility.c using
> > notification mechanism,
> > so it's safe to print something before tty driver is fully initialized
> > and
> > ready to receive. But. it seems all drivers and servers using printf in
> > libsysutil.
> >
> > Any suggestion futher?[/color]
>
> tty redefines its own kputc().
>
> =Ben[/color]

Hi

Obvious, it is silly question but excuse me :)
So, I found that "MINIX" is entry symbol in kernel, but
question is "how linker understand which symbol should be used as
entry point
-.o say only what "_start" should not be used, but how it know
what use instead


Al.
BIG Thanks.

The MINIX label in mpx*.s is at the very start of the .code section and
as such will be at address 0x0 in the .o. When the kernel is compiled,
mpx.o is specified to be the first object in the binary. As such, the
MINIX label will point to address 0x0 in the code segment of the
kernel. The bootloader will kick off execution from address 0x0.

Regards
Ivan

[email]al2.osd@gmail.com[/email] wrote:[color=blue]
> Hi
>
> Obvious, it is silly question but excuse me :)
> So, I found that "MINIX" is entry symbol in kernel, but
> question is "how linker understand which symbol should be used as
> entry point
> -.o say only what "_start" should not be used, but how it know
> what use instead
>
>
> Al.
> BIG Thanks.[/color]

[email]al2.osd@gmail.com[/email] wrote:[color=blue]
> Hi
>
> Obvious, it is silly question but excuse me :)
> So, I found that "MINIX" is entry symbol in kernel, but
> question is "how linker understand which symbol should be used as
> entry point
> -.o say only what "_start" should not be used, but how it know
> what use instead
>
>
> Al.
> BIG Thanks.[/color]

excuse me, i've missed

May be I've misunderstand you, but I saw in code what entry address
obtained from a.out header. Header constructed during linkage and
linker should choose from what symbol execution starts.
bootloader only reads header and starts kernel from certain address.


Al.

Ivan Kelly wrote:[color=blue]
> The MINIX label in mpx*.s is at the very start of the .code section and
> as such will be at address 0x0 in the .o. When the kernel is compiled,
> mpx.o is specified to be the first object in the binary. As such, the
> MINIX label will point to address 0x0 in the code segment of the
> kernel. The bootloader will kick off execution from address 0x0.
>
> Regards
> Ivan
>
> [email]al2.osd@gmail.com[/email] wrote:[color=green]
> > Hi
> >
> > Obvious, it is silly question but excuse me :)
> > So, I found that "MINIX" is entry symbol in kernel, but
> > question is "how linker understand which symbol should be used as
> > entry point
> > -.o say only what "_start" should not be used, but how it know
> > what use instead
> >
> >
> > Al.
> > BIG Thanks.[/color][/color]

Thanks !
Good point ! (Almost unnoticable)

I think Jorrit paper has a good explanation about this. I just skimmed
through it before.
My review on it reminds me of it now.

Tyson M Kim

Thanks Ben !

Good point ! (Almost unnoticable)

What I said is just kernel message while user-level systems use
msg-passing and user processes request the service from FS, which
delivers it to tty.

I think Jorrit paper has a good explanation about this. I just skimmed
it through before.
A review on it refreshes my memory out of it now.

Can I have a quick question regarding it ?

So when the tty redefines kputc(), Is the previously-defined kputc() in
/lib/sysutil/kputc.c overloaded with the redefined kputc() in tty.c by
the compiler according to the chain of header files ?

Thanks in advance.

Tyson M Kim

Ben Gras wrote:[color=blue]
> All,
>[color=green]
> > I know in-kernel procedure kprintf() in kernel/utility.c using
> > notification mechanism,
> > so it's safe to print something before tty driver is fully initialized
> > and
> > ready to receive. But. it seems all drivers and servers using printf in
> > libsysutil.
> >
> > Any suggestion futher?[/color]
>
> tty redefines its own kputc().
>
> =Ben[/color]

Yes I think I got this.
This is a language scoping matter. So the compiler takes care of it.

Thanks for paying attention.