What exactly happens when I hit the Enter button in terms of system_read interrupt, assembly?

Question

I have this code:

section .bss
    buff    resb 1
readfromkeyboard:
    mov     eax,3       ;specify system read
    mov     ebx,0       ;specify standard in -> keyboard
    mov     ecx,buff    ;where to store what is read
    mov     edx,1       ;read 1 byte
    int     0x80        ;tell linux to do everything above

    mov     eax,4       ;sys_write
    mov     ebx,1       ;Standard output
    mov     ecx,buff    ;what to print          
    mov     edx,1       ;how long to print
    int     0x80        ;tell linux to do everything above

which works fine.

When I start the process the cursor will start to blink in terminal and I am free to enter characters. At this point I am free to enter as many characters as I want, except when I hit "ENTER" 1 byte will be read and it will be printed in the terminal.

My question is, what is happening internally as I enter characters and as I hit Enter.. So I hit 'a' in my keyboard, and say 'c', where is this data stored at the moment? Are they already in the memory space addressed by 'buff' in my code? Why does Linux read when I hit Enter?

@glglgl Thanks for the edit, but why the comment 'oh please' ? — Koray Tugay, Jan 11 '15 at 10:06
Becaus i am sometimes a bit too harsh in my comments. I apologize for that. — glglgl, Jan 11 '15 at 10:13
The tty layer does input buffering when in "canonical" mode. It can be disabled via termios calls. Compare `cat` vs `stty -icanon;cat;stty +icanon` — ninjalj, Apr 21 '15 at 18:44

score 5 · Accepted Answer · answered Jan 11 '15 at 10:41

There is a long way from inputting to the application:

Hardware
Driver layer
Console layer
reading functions

Somewhere therein happens the treatment of lines, I think it is at the console layer. There you can input data which is processed on in lines.

If an application comes along and reads, it gets as many characters as it asks for, the remaining ones are kept for the next reading call.

If there are none remaining, it will wait until the next line is complete - or if the user presses ^D, which means to terminate the current read() call. If no data were entered before, read() returns 0, denoting EOF. In all other cases, read() returns the number of bytes read so far.

If no data were entered before, read() returns 0 : I am not sure if this is correct. I think it just waits for some data to be entered? — Koray Tugay, Apr 21 '15 at 17:13
@KorayTugay As I wrote: Upon pressing Strg-D, this waiting is stopped. — glglgl, Apr 21 '15 at 18:24

score 2 · Answer 2 · answered Apr 24 '15 at 02:13

@glglgl has a good answer there, but here's a more direct answer: The other characters are sitting in the read input buffer waiting for processing.

Since you appear to be talking about Linux here, the kernel has a buffer set aside specifically for this that is created when a character devices is registered. If you'd really like to dig into this deeply, I'd strongly suggest this article. When you get there, search for vfs_read and start reading. It's a very good write up!

score 1 · Answer 3 · answered Jan 11 '15 at 10:13

1

If you asked for 1 byte then the input function will never store any extra bytes at the memory at buff. Linux will only store the a at buff but certainly not the c

answered Jan 11 '15 at 10:13

Sep Roland

33,889
7
43
76

But I can still see the character 'c' in my screen as I hit the button, so it must be stored somewhere? – Koray Tugay Jan 11 '15 at 10:14
Sure, it's stored in the video ram and depending on the Linux implementation also in it's internal buffer but it won't make it to your *buff* because that would defy the meaning of the input functionality you chose (asking for 1) – Sep Roland Jan 11 '15 at 10:22
Ok thanks. And how about 'Enter'. Why am I allowed to enter as many characters as I want until I hit Enter? What happens with Enter? – Koray Tugay Jan 11 '15 at 10:23
This is a generic input function that deals with a series of characters. Asking for 1 is just a special case. ENTER is the trigger that stops the function in it's tracks. – Sep Roland Jan 11 '15 at 10:32
Can we say 'Enter' sends EOF? – Koray Tugay Jan 11 '15 at 10:33
As a matter of speech you could call it that way. (With redirected input the EOF could actually be interpreted as an ENTER). – Sep Roland Jan 11 '15 at 10:38
2

No. Not at all. Enter and EOF are completely distinct. Enter is End of Line, not of File. – glglgl Jan 11 '15 at 10:42
@glglgl Wikipedia says: On computer keyboards, the enter key in most cases causes a command line to operate its default function. So does it send a EOL or does it tell console to operate its default function? – Koray Tugay Jan 11 '15 at 10:50
@KorayTugay The enter key itself just sends the appropriate key code. The keyboard driver converts this to the EOL character (0x0D resp. `\n), which in turn is interpreted by the console to end a line as described. – glglgl Jan 11 '15 at 10:58
But why do I have to send an EOL so the console prints what I have written? What I want is as soon as I hit 'a' it should print 'a' again, not allowing me to enter any more characters. – Koray Tugay Jan 11 '15 at 10:59

score 1 · Answer 4 · answered Apr 24 '15 at 01:16

The linux terminal driver is reading the characters and buffering them in its own memory space. Because your terminal is in 'line' mode, this buffering continues until the ENTER key ends a line. At this point the data can be transferred into the buffer you supplied. You only asked for 1 character, so that's what you get and the remaining characters sit in the terminal driver's memory for your next read request.

What exactly happens when I hit the Enter button in terms of system_read interrupt, assembly?

4 Answers4