[RFC] Fix printk not handling ANSI escape codes

[James Clarke]

* i386/i386at/kd.c (kdstart): Moved escape sequence handling to new
kd_putc_esc function.
(kd_putc_esc): New function with logic from kdstart.
(kdcnputc): Call kd_putc_esc rather than kd_putc to allow for ANSI
escape codes.
* i386/i386at/kd.h (kd_putc_esc): New function.
---
 i386/i386at/kd.c | 63 +++-
 i386/i386at/kd.h |  1 +
 2 files changed, 40 insertions(+), 24 deletions(-)

diff --git a/i386/i386at/kd.c b/i386/i386at/kd.c
index 5656e83..52ba0b6 100644
--- a/i386/i386at/kd.c
+++ b/i386/i386at/kd.c
@@ -1059,7 +1059,6 @@ kdstart(struct tty *tp)
 {
spl_t   o_pri;
int ch;
-   unsigned char   c;
 
if (tp->t_state & TS_TTSTOP)
return;
@@ -1069,33 +1068,12 @@ kdstart(struct tty *tp)
break;
if ((tp->t_outq.c_cc <= 0) || (ch = getc(&tp->t_outq)) == -1)
break;
-   c = ch;
/*
 * Drop priority for long screen updates. ttstart() calls us at
 * spltty.
 */
o_pri = splsoftclock(); /* block timeout */
-   if (c == (K_ESC)) {
-   if (esc_spt == esc_seq) {
-   *(esc_spt++)=(K_ESC);
-   *(esc_spt) = '\0';
-   } else {
-   kd_putc((K_ESC));
-   esc_spt = esc_seq;
-   }
-   } else {
-   if (esc_spt - esc_seq) {
-   if (esc_spt - esc_seq > K_MAXESC - 1)
-   esc_spt = esc_seq;
-   else {
-   *(esc_spt++) = c;
-   *(esc_spt) = '\0';
-   kd_parseesc();
- }
-   } else {
-   kd_putc(c);
-   }
-   }
+   kd_putc(ch);
splx(o_pri);
}
if (tp->t_outq.c_cc <= TTLOWAT(tp)) {
@@ -1237,6 +1215,43 @@ kd_bellon(void)
 
 /*
  *
+ * Function kd_putc_esc():
+ *
+ * This function puts a character on the screen, handling escape
+ * sequences.
+ *
+ * input   : character to be displayed (or part of an escape code)
+ * output  : character is displayed, or some action is taken
+ *
+ */
+void
+kd_putc_esc(u_char c)
+{
+   if (c == (K_ESC)) {
+   if (esc_spt == esc_seq) {
+   *(esc_spt++)=(K_ESC);
+   *(esc_spt) = '\0';
+   } else {
+   kd_putc((K_ESC));
+   esc_spt = esc_seq;
+   }
+   } else {
+   if (esc_spt - esc_seq) {
+   if (esc_spt - esc_seq > K_MAXESC - 1)
+   esc_spt = esc_seq;
+   else {
+   *(esc_spt++) = c;
+   *(esc_spt) = '\0';
+   kd_parseesc();
+   }
+   } else {
+   kd_putc(c);
+   }
+   }
+}
+
+/*
+ *
  * Function kd_putc():
  *
  * This function simply puts a character on the screen.  It does some
@@ -2950,7 +2965,7 @@ kdcnputc(dev_t dev, int c)
/* Note that tab is handled in kd_putc */
if (c == '\n')
kd_putc('\r');
-   kd_putc(c);
+   kd_putc_esc(c);
 
return 0;
 }
diff --git a/i386/i386at/kd.h b/i386/i386at/kd.h
index 0cfed69..60cee7e 100644
--- a/i386/i386at/kd.h
+++ b/i386/i386at/kd.h
@@ -702,6 +702,7 @@ extern void kd_setleds1 (u_char);
 extern void kd_setleds2 (void);
 extern void cnsetleds (u_char);
 extern void kdreboot (void);
+extern void kd_putc_esc (u_char);
 extern void kd_putc (u_char);
 extern void kd_parseesc (void);
 extern void kd_down (void);
-- 
2.5.1

Re: [RFC] Fix printk not handling ANSI escape codes

[Samuel Thibault]

James Clarke, le Sat 29 Aug 2015 11:15:29 +0100, a écrit :
> @@ -1069,33 +1068,12 @@ kdstart(struct tty *tp)
>   break;
>   if ((tp->t_outq.c_cc <= 0) || (ch = getc(&tp->t_outq)) == -1)
>   break;
> - c = ch;
>   /*
>* Drop priority for long screen updates. ttstart() calls us at
>* spltty.
>*/
>   o_pri = splsoftclock(); /* block timeout */
> - if (c == (K_ESC)) {
...
> - }
> + kd_putc(ch);

I don't understand: shouldn't that be kd_putc_esc?

Samuel

Re: [RFC] Fix printk not handling ANSI escape codes

[James Clarke]

Yes, it should be; since I didn't catch that I'd guess nothing in Mach/Hurd is 
actually using escape codes.

I was trying to decide whether putc should handle escape codes or whether it 
should be left as outputting raw bytes to the display. As you can see I chose 
the latter, but do you think that was the right decision?

James

> On 29 Aug 2015, at 11:20, Samuel Thibault  wrote:
> 
> James Clarke, le Sat 29 Aug 2015 11:15:29 +0100, a écrit :
>> @@ -1069,33 +1068,12 @@ kdstart(struct tty *tp)
>>break;
>>if ((tp->t_outq.c_cc <= 0) || (ch = getc(&tp->t_outq)) == -1)
>>break;
>> -c = ch;
>>/*
>> * Drop priority for long screen updates. ttstart() calls us at
>> * spltty.
>> */
>>o_pri = splsoftclock();/* block timeout */
>> -if (c == (K_ESC)) {
> ...
>> -}
>> +kd_putc(ch);
> 
> I don't understand: shouldn't that be kd_putc_esc?
> 
> Samuel

Re: [RFC] Fix printk not handling ANSI escape codes

[Samuel Thibault]

James Clarke, le Sat 29 Aug 2015 11:42:38 +0100, a écrit :
> Yes, it should be; since I didn't catch that I'd guess nothing in Mach/Hurd 
> is actually using escape codes.
> 
> I was trying to decide whether putc should handle escape codes or whether it 
> should be left as outputting raw bytes to the display. As you can see I chose 
> the latter, but do you think that was the right decision?

Well, I don't see why we would want to forbid the use of ESC sequences
in Mach/Hurd :)

Samuel

Re: [RFC] Fix printk not handling ANSI escape codes

[James Clarke]

I never gave that as an option?

James

> On 29 Aug 2015, at 11:44, Samuel Thibault  wrote:
> 
> James Clarke, le Sat 29 Aug 2015 11:42:38 +0100, a écrit :
>> Yes, it should be; since I didn't catch that I'd guess nothing in Mach/Hurd 
>> is actually using escape codes.
>> 
>> I was trying to decide whether putc should handle escape codes or whether it 
>> should be left as outputting raw bytes to the display. As you can see I 
>> chose the latter, but do you think that was the right decision?
> 
> Well, I don't see why we would want to forbid the use of ESC sequences
> in Mach/Hurd :)
> 
> Samuel

Re: [RFC] Fix printk not handling ANSI escape codes

[Samuel Thibault]

James Clarke, le Sat 29 Aug 2015 11:53:57 +0100, a écrit :
> I never gave that as an option?

? I understand even less.  AIUI, before kd_start had esc support; with
your patch it doesn't have any more.  Probably Mach/Hurd never made use
of it, but that's probably not a reason for removing the support, you
never know who might want to make use of it someday.

Samuel

Re: [RFC] Fix printk not handling ANSI escape codes

[James Clarke]

Yes, that was a mistake, it should call kd_putc_esc.

James

> On 29 Aug 2015, at 11:55, Samuel Thibault  wrote:
> 
> James Clarke, le Sat 29 Aug 2015 11:53:57 +0100, a écrit :
>> I never gave that as an option?
> 
> ? I understand even less.  AIUI, before kd_start had esc support; with
> your patch it doesn't have any more.  Probably Mach/Hurd never made use
> of it, but that's probably not a reason for removing the support, you
> never know who might want to make use of it someday.
> 
> Samuel

Re: netdde drivers

[Robert Millan]

Hi Samuel

El 29/08/15 a les 00:17, Samuel Thibault ha escrit:

Hello,

As it seems we'll never synchronize netdde with DDE but rather go with
Rump,


That's an interesting proposition. Is someone working on a Rump-based
network translator?

FYI, I'm currently trying to get the remaining parts of my Rump port
merged. Other than that, let me know if I can be of any help.

--
Robert Millan

Re: netdde drivers

[Samuel Thibault]

Robert Millan, le Sat 29 Aug 2015 21:37:04 +0200, a écrit :
> El 29/08/15 a les 00:17, Samuel Thibault ha escrit:
> >As it seems we'll never synchronize netdde with DDE but rather go with
> >Rump,
> 
> That's an interesting proposition. Is someone working on a Rump-based
> network translator?

Not that I'm aware of, but I guess the task is not so hard now that you
got sound working.

Samuel

ext2fs crashes

[Samuel Thibault]

Hello,

Just to report that ext2fs crashes from times to times with 

ext2fs: ../../libports/../libshouldbeinlibc/refcount.h:165:
refcounts_ref: Assertion `! (r.hard == 1 && r.weak == 0) || !"refcount
detected use-after-free!"' failed.

Samuel

Re: [RFC] Fix printk not handling ANSI escape codes

[Samuel Thibault]

Applied with the kd_putc_esc call fixed, thanks!

Samuel

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

[Samuel Thibault]

Hello,

Thanks for working on this!

Flávio Cruz, le Sat 29 Aug 2015 03:35:56 +0100, a écrit :
> These two patches allow the glibc and the hurd servers to handle UTIME_OMIT 
> and UTIME_NOW in futimens.
> The file_utimes RPC now uses a struct timespec instead of a timeval.

Well, we can't really change RPCs on the fly like this, otherwise you
can't upgrade running translators first or libc first.  You need to
introduce a new RPC with the new interface, and in libc cope with
translators which don't know the new RPC yet by reverting to the old
RPC.

Samuel

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

[Samuel Thibault]

Samuel Thibault, le Sun 30 Aug 2015 02:24:46 +0200, a écrit :
> Flávio Cruz, le Sat 29 Aug 2015 03:35:56 +0100, a écrit :
> > These two patches allow the glibc and the hurd servers to handle UTIME_OMIT 
> > and UTIME_NOW in futimens.
> > The file_utimes RPC now uses a struct timespec instead of a timeval.
> 
> Well, we can't really change RPCs on the fly like this, otherwise you
> can't upgrade running translators first or libc first.  You need to
> introduce a new RPC with the new interface, and in libc cope with
> translators which don't know the new RPC yet by reverting to the old
> RPC.

(And translators should keep serving both RPCs, for applications running
with old libc).

Samuel

Re: netdde drivers

[Diego Nieto Cid]

Hi

Sorry, I meant to send this to the list too but failed to do so.

El sáb., 29 de agosto de 2015 17:58, Robert Millan  escribió:

El 29/08/15 a les 21:56, Diego Nieto Cid ha escrit:
>


>
> Hi
>
>
> El sáb., 29 de agosto de 2015 16:37, Robert Millan > escribió:
>
>
>
> That's an interesting proposition. Is someone working on a Rump-based
> network translator?
>
> FYI, I'm currently trying to get the remaining parts of my Rump port
> merged. Other than that, let me know if I can be of any help.
>
> --
> Robert Millan
>
>
> I intend to work on user-mode device drivers as part of my thesis. My
first option was working on rump (you beat me he he). Or DDE if that was
not possible.
>
> But not quite yet. I'm on vacation for a week and then I have to do some
writing. So I'm not sure when I'll be able to start coding.

Hi Diego,

Well I tried both too. You might want to check my Bachelor's thesis as it
includes a
detailed comparison and explanation on why I chose to use Rump afterwards:

https

://

github.com

/

rumpkernel

/wiki/wiki/

Info%3A-

Publications-and-

Talks#theses


Good luck!

--
Robert Millan


Thanks, I will have a look, it sounds interesting.

Actually, I don't know yet what I'll specifically do. I just thought that
if I'll  spend 6 months to a year working on something it would be nice if
it were useful for this project :)