Re: [RFC] Fix printk not handling ANSI escape codes
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, 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
Yes, that was a mistake, it should call kd_putc_esc. James On 29 Aug 2015, at 11:55, Samuel Thibault samuel.thiba...@gnu.org 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: [RFC] Fix printk not handling ANSI escape codes
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
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 samuel.thiba...@gnu.org 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
I never gave that as an option? James On 29 Aug 2015, at 11:44, Samuel Thibault samuel.thiba...@gnu.org 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
[RFC] Fix printk not handling ANSI escape codes
* 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: netdde drivers
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
Re: netdde drivers
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 r...@gnu.org 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 r...@gnu.org mailto: r...@gnu.org 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 https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses :// https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses github.com https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses / https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses rumpkernel https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses /wiki/wiki/ https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses Info%3A- https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses Publications-and- https://github.com/rumpkernel/wiki/wiki/Info%3A-Publications-and-Talks#theses Talks#theses 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 :)
ext2fs crashes
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: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.
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, 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
