How can I test my console driver?

How can I test my console driver?

[Alex Bennee]

I sent this to lkml but it probably got missed in the volume of mail.
Can anyone point me anything that describes how I could test my console
driver. Would it be the same approach for example as testing the vfb
frame buffer driver?

-----Forwarded Message-----
> Hi,
> 
> I'm writting a console driver for an embedded system for which the
> hardware isn't quite ready yet. As a result I'm building on a PC with a
> quickly hacked up proc interface so I can test the logic before the
> final hardware.
> 
> On loading the module my code does the following:
> 
>     take_over_console(&sh_con, MAX_NR_CONSOLES - 1, MAX_NR_CONSOLES - 1,
> 1);
> 
> Which I understand should associate my new console driver with the last
> system console (63 in this case). Then to test the console output I do:
> 
>     echo "this is a test string" > /dev/vc/63
> 
> However my dmesg output shows no sign of any of the console functions
> being called to write data, although the module itself has loaded
> succesfully and run the take_over_console code.
> 
> Obviously I'm mis-understanding how the console should be accessed but
> I'm stuck looking for any pointers. I've been looking thorugh the
> newport_con.c driver for pointers but so far I've not seen any extra
> magic that I'm missing. Can anyone point me in the right direction/offer
> some tips?
> 

-- 
Alex, homepage: http://www.bennee.com/~alex/

It's not reality or how you perceive things that's important -- it's
what you're taking for it...



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: How can I test my console driver?

[Antonino Daplas]

On Tue, 2003-03-11 at 17:52, Alex Bennee wrote:
> I sent this to lkml but it probably got missed in the volume of mail.
> Can anyone point me anything that describes how I could test my console
> driver. Would it be the same approach for example as testing the vfb
> frame buffer driver?
> 
> -----Forwarded Message-----
> > Hi,
> > 
> > I'm writting a console driver for an embedded system for which the
> > hardware isn't quite ready yet. As a result I'm building on a PC with a
> > quickly hacked up proc interface so I can test the logic before the
> > final hardware.
> > 
> > On loading the module my code does the following:
> > 
> >     take_over_console(&sh_con, MAX_NR_CONSOLES - 1, MAX_NR_CONSOLES - 1,
> > 1);
> > 
> > Which I understand should associate my new console driver with the last
> > system console (63 in this case). Then to test the console output I do:
> > 
> >     echo "this is a test string" > /dev/vc/63
> > 

I think the above will not work.  You can only have 1 active console at
a time, so all inputs to an inactive console will be buffered.  Only
when you switch to that particular console that all pending commands
will be flushed. 

Why not just use take_over_console() with first and last equal to a tty
you can switch to?  If something bad happens, just switch to a working
console.

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: How can I test my console driver?

[Alex Bennee]

On Tue, 2003-03-11 at 12:59, Antonino Daplas wrote:
> On Tue, 2003-03-11 at 17:52, Alex Bennee wrote:
> > > <snip>
> > > On loading the module my code does the following:
> > > 
> > >     take_over_console(&sh_con, MAX_NR_CONSOLES - 1, MAX_NR_CONSOLES - 1,
> > > 1);
> > > 
> > > Which I understand should associate my new console driver with the last
> > > system console (63 in this case). Then to test the console output I do:
> > > 
> > >     echo "this is a test string" > /dev/vc/63
> > > 
> 
> I think the above will not work.  You can only have 1 active console at
> a time, so all inputs to an inactive console will be buffered.  Only
> when you switch to that particular console that all pending commands
> will be flushed. 
> 
> Why not just use take_over_console() with first and last equal to a tty
> you can switch to?  If something bad happens, just switch to a working
> console.

I tried that. It seems the first time I do a Ctrl-Alt-5 (for example) I
loose the ability to use my keyboard. The only way I can recover
anything is to re-boot my machine. This strikes me as a little odd as I
thought the console was soley interested in output.

Is there anyway to write unbuffered output to the console? After all the
only way I'm going to know anything is working is through dmesg and/or
the screen image I read from my debugging proc interface.

-- 
Alex, homepage: http://www.bennee.com/~alex/

The soul would have no rainbow had the eyes no tears.



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: How can I test my console driver?

[Antonino Daplas]

On Tue, 2003-03-11 at 22:28, Alex Bennee wrote:
> > Why not just use take_over_console() with first and last equal to a tty
> > you can switch to?  If something bad happens, just switch to a working
> > console.
> 
> I tried that. It seems the first time I do a Ctrl-Alt-5 (for example) I
> loose the ability to use my keyboard. The only way I can recover
> anything is to re-boot my machine. This strikes me as a little odd as I
> thought the console was soley interested in output.
> 
> Is there anyway to write unbuffered output to the console? After all the
> only way I'm going to know anything is working is through dmesg and/or
> the screen image I read from my debugging proc interface.
> 

Maybe you can create dummy methods first, con_startup, con_init (used
during take_over_console), as well as the putc/s, scroll, clear, bmove,
etc.  Then you can implement them one by one and see which method
actually triggerred the lockup.

Tony 




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en