Keyboard driver

[Pype.Clicker]

fscanf will apply backspaces and other keys before pass the input to the kernel.

That means you'll be unable to use things like tab-completion or history navigation in your shell right from the start...

No, seriously, just get characters from the keyboard, and do the echo-on-screen and store-in-line-buffer until "RET" is pressed within the shell.

Plus, i fear what you need is more a "fgets" than a "fscanf" ...

In which way could i use irq01?

install a IRQ handler for it. might help

is the same if i'll read the characters in the loop and see if they changed?

no, it's not. Using poll-in-a-loop, you'll never be able to use the typematic feature of your keyboard (e.g. if you keep the 'backspace' key pressed because you want to erase much stuff, the scancode don't change but you receive periodic IRQs until key is released).
Plus you'll be messing everything up as soon as a PS2 mouse will be involved aswell.

[SpiglerG]

i'll try to implement irq1.

my scanf idea is that, because of the kernel at this point is mono task, the function will stop all the kernel execution and wait for a command.
when the user will press enter the function will return the inserted text to the kernel, which will stop that function and elaborate the result. then it will execute the command action and re-call scanf.
when i'll evolve to multi-tasking, the function will be modified to share the procssor usage with the other processes such as gui and/or user programs. when the kernel is only a shell, multitasking isn't necessary because there is only a command shell(unless you use more than one).

[Solar]

Don't mix up stuff that simply does not belong together!

You have three very individual tasks at hand here:

• line editing - when a key is pressed, write a character to buffer (or delete it in case of backspace) until return is pressed.
• line parsing - taking the string from buffer (because return has been pressed) and tokenizing it.
• command interface - acting on the input.

Look at it from the other side. A command shell like bash - a user space application! - calls readline() or scanf() or something to parse the next line of input. That function pauses until a line of input is ready (kernel space!). The shell now has the string entered, can parse it, do internal stuff ("export var=X"), or call a program, which is quite another call to a completely different kernel service.

You're trying to mix up too many things here. What you need now isn't a scanf()-like line parser, you need a line buffer first. Don't worry about the parsing, just come up with a function that allows line editing and echoes that line back to screen. Worry about parsing and starting programs etc. after you have finished the line editing stuff...

[SpiglerG]

those was only examples.
i'll try to write some scanf functions for test purpose.

[Solar]

those was only examples.
i'll try to write some scanf functions for test purpose.

How? The scanf() family expects to parse a char * of the line you entered. As long as you don't have the buffer and the line editing implemented, you don't have anything to give to any scanf(), since that buffer and the line editing is not anything that scanf() should have to do.

That's what I tried to say: You're putting too much into scanf().

scanf( const char *, ... ) is a wrapper for fscanf( stdin, const char *, ... ). Both parse one char * given to them by some kind of input stream (console, file, serial, ...) by the format definition contained in another char * (the one passed as parameter).

Neither scanf() function bothers about where that char * actually comes from (some file descriptor). Thus, you need another function that provides that char * from the console. That functionality doesn't belong into scanf(), and not into k_scanf() either (since you'll probably want to re-use the scanf() parsing code later on, will you?)

That's why I recommended writing that "echoing" function first. It provides the char * you can then parse with some k_scanf() if you like.

[Solar]

If it helps, consider that gets() requires the very same const * to the string just entered, just like scanf(). You wouldn't want to write the keyboard handling stuff in both gets() and scanf(), would you?

[SpiglerG]

if i make them different, the answer is that i would have gets AND scanf.

[Solar]

Sorry, I cannot make sense of that last sentence...

[distantvoices]

@SpiglerG: you build scanf() as a userland library function around a sound and fine gets() call - or, if you want so, a getch(), we are not picky about that. But you definitely don't need scanf() in kernel land, get me?

So in short: NO, you don't get gets() AND scanf(), you get gets() and then scanf() buildt on top of gets(). We don't want to do things more often than necessary. But at the end, that's to you. But don't come along whining that it doesn't work out as expected if you insist on *certain* plans of your own, ok? We do things the way we do them out of a purpose know ya?

Stay safe. and be happy that I'm not as scournful as I could have been - I'm in a rather good mood today.

[Solar]

...be happy that I'm not as scournful as I could have been - I'm in a rather good mood today.

Down! Bad dog!



But it's true. A good rule to follow in crafting stuff like this is finding out how others did it. Sometimes you know something is just wrong, and why - then do it differently. But if you cannot say that, give it the benefit of doubt and assume they're right.

And I'm not talking about beyond_infinity and myself here, but "classical" C library implementations.

[distantvoices]

*growls at solar and feels perfectly like a big baaad dooog*

Actually, I've got a t-shirt with a "Bad Dog" imprint. I've bought it in America six years ago. *chuckle*

[Solar]

I've bought it in America six years ago. *chuckle*

How come they didn't detain you?

[distantvoices]

Oh, they didn't need to know, so I've got around pretty fine.

[Candy]

Oh, they didn't need to know.

You're keeping the CIA, NSA and FBI on a need-to-know basis?

[distantvoices]

@candy: *rofl* How deducest thou that by "they" those institutions are meant?

Anyways, these which you mean - they especially need not to know what's in my travelling bags as long as I don't carry around bombs and drugs - which isn't likely to ever happen for I'm not interrested in that sorta things - rather snogging, cooking, travelling and osdeving, eh? *chuckle*