Console API related patch.

2003-02-16 Thread Poul-Henning Kamp 

I am trying to do some weird things with some custom console code and
got stuck on the fact that our console code belives all consoles have
a dev_t.

This patch changes the API so that rather than pass a dev_t to the
console functions, the struct consdev * is passed:

-typedefvoidcn_putc_t(dev_t, int);
+typedefvoidcn_putc_t(struct consdev *, int);

The dev_t can still be gotten hold of:

 int
-zs_cncheckc(dev_t dev)
+zs_cncheckc(struct consdev *cp)
 {
int s = spltty();
-   int c = zs_maygetc(zs_console_addr, minor(dev));
+   int c = zs_maygetc(zs_console_addr, minor(cp-cn_dev));
splx(s);
return c;
 }

But in addition to this I have added a driver-private element to the
consdev structure for other needs:

+   void*cn_arg;/* drivers method argument */

The patch compiles and runs on all platforms I can currently test,
but I'd like if some of you can give it a spin too:

http://phk.freebsd.dk/patch/console.patch

The patch just does the not quite mechanical switch, some of the drivers
could get some mileage from the cn_arg field but I have not tried that.

Thanks in advance,

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Console API related patch.

2003-02-16 Thread Marcel Moolenaar 
On Sun, Feb 16, 2003 at 09:45:28PM +0100, Poul-Henning Kamp wrote:
 
 I am trying to do some weird things with some custom console code and
 got stuck on the fact that our console code belives all consoles have
 a dev_t.
 
 This patch changes the API so that rather than pass a dev_t to the
 console functions, the struct consdev * is passed:
 
   -typedefvoidcn_putc_t(dev_t, int);
   +typedefvoidcn_putc_t(struct consdev *, int);
 
 The dev_t can still be gotten hold of:
 
int
   -zs_cncheckc(dev_t dev)
   +zs_cncheckc(struct consdev *cp)
{
   int s = spltty();
   -   int c = zs_maygetc(zs_console_addr, minor(dev));
   +   int c = zs_maygetc(zs_console_addr, minor(cp-cn_dev));
   splx(s);
   return c;
}

I like this. On the ia64 branch I completely ignore the dev argument
and instead use a static softc. The dev_t is unknown until after
bus enumeration in principle anyway.

 The patch compiles and runs on all platforms I can currently test,
 but I'd like if some of you can give it a spin too:
 
   http://phk.freebsd.dk/patch/console.patch
 
 The patch just does the not quite mechanical switch, some of the drivers
 could get some mileage from the cn_arg field but I have not tried that.

I'll test ia64, both CVS an P4. Let me know when you like to
commit this so that I can schedule around that...

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Console API related patch.

2003-02-16 Thread phk 
In message [EMAIL PROTECTED], Marcel Moolenaar writes:

 This patch changes the API so that rather than pass a dev_t to the
 console functions, the struct consdev * is passed:
 
  -typedefvoidcn_putc_t(dev_t, int);
  +typedefvoidcn_putc_t(struct consdev *, int);
 

I like this. On the ia64 branch I completely ignore the dev argument
and instead use a static softc. The dev_t is unknown until after
bus enumeration in principle anyway.

Yeah, I saw that.  Actually I think more or less any console driver
which uses the dev_t arg is wrong about doing that, but we can
fix that subsequently.

I'll test ia64, both CVS an P4. Let me know when you like to
commit this so that I can schedule around that...

I'm no no particular hurry, so whenever I have sufficient feedback to
convince me that its safe.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message