From: Jörgen Sigvardsson <jorgen.sigvardsson@kau.se>
Subject: Design question...
Date: Wed, 28 Feb 2001 12:27:02 +0100
Next Article (by Subject): direct access to devices Arkady A Drovosekov
Previous Article (by Subject): Design bugs Stanislav Ievlev
Articles sorted by: [Date]
[Author]
[Subject]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Right now I'm cooking up a proc-entry for myself which allows for registration of signature keys. By registering a key you have to write something like this to my proc-entry: - --->8---- AddRSAKey CN=Jorgen Sigvardsson EM=jorgen.sigvardsson@kau.se 3 1234567 - --->8---- Basically it's a command specifier (1st line), an id line (typically an X.509-like name), an e-parameter for RSA (e-part of public key) and an n-parameter for RSA (n-part of public key). I have implemented my own file operations[1] for this proc entry which deals with reading[2] and writing to the proc file. Now here's the question: Is it bad to require that the user process must do an atomic write per command? With atomic I mean write(fd, "AddRSAKey....", length). Right now I cannot handle stuff like: buf = "AddRSAKey..."; for(i = 0; i < strlen(buf); i++) write(fd, &buf[i], 1); I don't want to go into parsing-orgies within the kernel.. ;) write returns of course the length of what was "accepted", thus a chunk of several commands in the same buffer will be accepted IFF the user program is written correctly (i.e., it pays respect to what write() returns). I think "weird" write semantics weighs heavier than utterly complex and error prone kernel code.. what do you guys think? [1] proc_info is a nightmare for returning anything larger than 4k.. for a real code-mess, have a look at proc_file_read in fs/proc/generic.c [2] reading returns a list of registered keys - -- Jörgen Sigvardsson, B. Sc. Lecturer, Computer Science Dept. Karlstad University Tel: +46-(0)54-700 1786 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: For info see http://www.gnupg.org iD4DBQE6nOCGJtcD8rikkmwRAo+VAJ97HYZOGhfQnpV6Of2IsYP/CfsADwCY3O3I HcBi9BMMgyeUUplapqjB/g== =MkrX -----END PGP SIGNATURE----- - To unsubscribe from the rsbac list, send a mail to majordomo@rsbac.org with unsubscribe rsbac as single line in the body.
Next Article (by Subject): direct access to devices Arkady A Drovosekov
Previous Article (by Subject): Design bugs Stanislav Ievlev
Articles sorted by: [Date]
[Author]
[Subject]