Hi,
I have a number of functions that used to drive a device on an embedded
system. Now that we are moving to Linux, these functions are part of the
kernel space. My question is : what is the best way to access these
from user space ?
With a device driver, is it not a problem to implement about 15 commands through
ioctl in addition to the usual open, close, read write ? It seems a bit
awkward ...
Any advice on this will help a lot. Thanks in advance,
Ivan
On 9/15/05, Ivan Korzakow <[email protected]> wrote:
> I have a number of functions that used to drive a device on an embedded
> system. Now that we are moving to Linux, these functions are part of the
> kernel space. My question is : what is the best way to access these
> from user space ?
> With a device driver, is it not a problem to implement about 15 commands through
> ioctl in addition to the usual open, close, read write ? It seems a bit
> awkward ...
>
> Any advice on this will help a lot. Thanks in advance,
>
Adding ioctl in driver is not a good idea especially for 2.6.x series
kernel, rather use sysfs which is in kernel 2.6.x to support
user/kernel interaction too with other usage .....
--
Fawad Lateef
>
> Adding ioctl in driver is not a good idea especially for 2.6.x series
> kernel, rather use sysfs which is in kernel 2.6.x to support
> user/kernel interaction too with other usage .....
>
Thanks for your answer. I started looking in sysfs and driver model.
Could you explain me why ioctl should be avoided ? Is it going to be
deprecated in future kernel ?
Regards,
Ivan
On 9/15/05, Ivan Korzakow <[email protected]> wrote:
> >
> > Adding ioctl in driver is not a good idea especially for 2.6.x series
> > kernel, rather use sysfs which is in kernel 2.6.x to support
> > user/kernel interaction too with other usage .....
> >
>
>
> Thanks for your answer. I started looking in sysfs and driver model.
>
> Could you explain me why ioctl should be avoided ? Is it going to be
> deprecated in future kernel ?
>
No ioctl are not deprecated, but they are just avoided b/c its not
good to mess kernel with new system-calls as there is a different way
for that !!!!
And for user/kernel interaction you have to look for sysfs/kobject and
don't need to go into the details of driver-model if you just need to
do user/kernel interaction and linux device driver 3rd edition's
chapter of driver-model will really help you in user/kernel
interaction (http://lwn.net/Kernel/ldd3/) ...... (for bi-directional
communication means kernel can also send messeges to user space you
can see netlink-sockets) .........
--
Fawad Lateef
On 15 Sep 2005, Fawad Lateef stated:
> On 9/15/05, Ivan Korzakow <[email protected]> wrote:
>> Could you explain me why ioctl should be avoided ? Is it going to be
>> deprecated in future kernel ?
>
> No ioctl are not deprecated, but they are just avoided b/c its not
> good to mess kernel with new system-calls as there is a different way
> for that !!!!
Well, not really; ioctl() is only one system call. They're actually
avoided because ioctl() has a horrible non-typesafe non-transparent
interface. (Quick! What parameters does the CCISS_PASSTHRU32 ioctl()
expect?)
sysfs fixes all of these problems, and adds easy scriptability
and interrogation from the command-line and a nice hierarchy
as well.
New *system calls* are generally avoided (especially if they might be
useful to non-privileged code) because they come with a *very* high
backward compatibility burden: it's pretty much the case that syscalls
that normal programs rely on should never go away. (Syscalls used only
by programs that you expect to change with the kernel, like modutils/
module-init-tools, are a special case.)
--
`One cannot, after all, be expected to read every single word
of a book whose author one wishes to insult.' --- Richard Dawkins
> New *system calls* are generally avoided (especially if they might be
> useful to non-privileged code) because they come with a *very* high
> backward compatibility burden
ioctls come with the same burden though.
On 16 Sep 2005, Arjan van de Ven noted:
>
>> New *system calls* are generally avoided (especially if they might be
>> useful to non-privileged code) because they come with a *very* high
>> backward compatibility burden
>
> ioctls come with the same burden though.
Well, sort of. A lot of ioctl()s are widely-known and surely can't be
changed, just like syscalls (e.g. the terminal control stuff) --- but
in the past even things like the HD geometry ioctls have changed,
and ioctl()s specific to, say, a single obscure block device could
probably change without requiring recompilation of more than one or
two userspace programs (and this has happened).
Indeed, one of the problems with ioctl()s is that there is no clear
delineation: some ioctl()s are heavily used and some are totally
unused, and it's never clear which is which in all cases.
(I suppose this is sort of true of syscalls too --- how many people call
sys_uselib()? --- but to a much lesser extent, because there's no such
thing as an `obscure device-specific syscall'.)
--
`One cannot, after all, be expected to read every single word
of a book whose author one wishes to insult.' --- Richard Dawkins
On Fri, 16 Sep 2005, Nix wrote:
> On 16 Sep 2005, Arjan van de Ven noted:
>>
>>> New *system calls* are generally avoided (especially if they might be
>>> useful to non-privileged code) because they come with a *very* high
>>> backward compatibility burden
>>
>> ioctls come with the same burden though.
>
> Well, sort of. A lot of ioctl()s are widely-known and surely can't be
> changed, just like syscalls (e.g. the terminal control stuff) --- but
> in the past even things like the HD geometry ioctls have changed,
> and ioctl()s specific to, say, a single obscure block device could
> probably change without requiring recompilation of more than one or
> two userspace programs (and this has happened).
>
> Indeed, one of the problems with ioctl()s is that there is no clear
> delineation: some ioctl()s are heavily used and some are totally
> unused, and it's never clear which is which in all cases.
>
> (I suppose this is sort of true of syscalls too --- how many people call
> sys_uselib()? --- but to a much lesser extent, because there's no such
> thing as an `obscure device-specific syscall'.)
>
> --
> `One cannot, after all, be expected to read every single word
> of a book whose author one wishes to insult.' --- Richard Dawkins
> -
But an ioctl is supposed to be specific to your device. After all,
you access it with a fd obtained by opening your device. To keep
`strace` from "interpreting" your ioctl function-code, it was
common to start device-specific ioctl function values higher than
the ones used by common kernel devices.
Using another interface to provide device-specific control is
more "Sun-like", "BSD-like", or "Linux-like", not necessarily
bad or good. The defacto "Unix" way is to use ioctl(). That's
what it was provided for; "The ioctl() function manipilates the
underlying device parameters of special files." -- from the
AT&T System-V release 2 programmer's reference manual.
Somebody reported to me that there was some special "optimization"
in Linux that interpreted ioctl() function calls without regard
to the specific device that was open (gawd I hope not), and that
if you used "already-used" function numbers for your device-specific
ioctl(), then strange things would occur. If true, then that is
a bug. Code inspection of fs/ioctl.c doesn't show this to be
the case. However, the kernel is now LOCKED during an ioctl()
call. Older Linux versions didn't lock the kernel. The upshot
of this is that if you have some ioctl() function that takes
some time, like testing the memory in your board, you will
find the system unresponsive during that test! You can unlock
the kernel in your ioctl() if this is a problem.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Fri, Sep 16, 2005 at 01:59:22PM +0100, Nix wrote:
> Quick! What parameters does the CCISS_PASSTHRU32 ioctl() expect?)
Added to Documentation/ioctl-mess.txt, thanks. ;-)
On Sep 16, 2005, at 12:02:59, linux-os (Dick Johnson) wrote:
> Somebody reported to me that there was some special "optimization"
> in Linux that interpreted ioctl() function calls without regard to
> the specific device that was open (gawd I hope not), and that if
> you used "already-used" function numbers for your device-specific
> ioctl(), then strange things would occur.
IIRC, that used to be the case, but isn't anymore.
> However, the kernel is now LOCKED during an ioctl() call. Older
> Linux versions didn't lock the kernel. The upshotof this is that if
> you have some ioctl() function that takes some time, like testing
> the memory in your board, you will find the system unresponsive
> during that test! You can unlock the kernel in your ioctl() if this
> is a problem.
This is *completely* wrong. The kernel used to lock_kernel() for
*every* ioctl. Recent changes added locked and unlocked ioctls, such
that ioctls that do not need the BKL can ignore it completely. You
claimed to have read the code, given this typical Wrongbot statement,
I guess I can say for sure that you didn't.
Cheers,
Kyle Moffett
--
Premature optimization is the root of all evil in programming
-- C.A.R. Hoare
PS: Use a different email service! Your "I tried to kill it with
the above dot" and bullshit apology is worth zilch. A quick
calculation shows that over the last month and a half, you have
sent 76 or so emails to the list, all of which have contained your
useless 663-byte corporate message, meaning you have sent 50K of spam
to the list over that time period, which has been distributed to
several thousand accounts by vger, resulting in probably over 100MB
of spam over that time period. Fix it or use a different email account!
I am not the intended recipient for the following email text. I will
destroy all copies of this information, including further copies of
it, because I am not the intended recipient of those either. Plonk!
> .
> I apologize for the following. I tried to kill it with the above dot :
>
> ****************************************************************
> The information transmitted in this message is confidential and may
> be privileged. Any review, retransmission, dissemination, or other
> use of this information by persons or entities other than the
> intended recipient is prohibited. If you are not the intended
> recipient, please notify Analogic Corporation immediately - by
> replying to this message or by sending an email to
> [email protected] - and destroy all copies of this
> information, including any attachments, without reading or
> disclosing them.
>
> Thank you.
On Fri, 16 Sep 2005, Kyle Moffett wrote:
> On Sep 16, 2005, at 12:02:59, linux-os (Dick Johnson) wrote:
>> Somebody reported to me that there was some special "optimization"
>> in Linux that interpreted ioctl() function calls without regard to
>> the specific device that was open (gawd I hope not), and that if
>> you used "already-used" function numbers for your device-specific
>> ioctl(), then strange things would occur.
>
> IIRC, that used to be the case, but isn't anymore.
>
>> However, the kernel is now LOCKED during an ioctl() call. Older
>> Linux versions didn't lock the kernel. The upshotof this is that if
>> you have some ioctl() function that takes some time, like testing
>> the memory in your board, you will find the system unresponsive
>> during that test! You can unlock the kernel in your ioctl() if this
>> is a problem.
>
> This is *completely* wrong. The kernel used to lock_kernel() for
> *every* ioctl. Recent changes added locked and unlocked ioctls, such
> that ioctls that do not need the BKL can ignore it completely. You
> claimed to have read the code, given this typical Wrongbot statement,
> I guess I can say for sure that you didn't.
>
If you are really interested, put a 'if(kernel_locked())' in your
favorite ioctl(), and then respond with an apology.
> Cheers,
> Kyle Moffett
>
> --
> Premature optimization is the root of all evil in programming
> -- C.A.R. Hoare
>
> PS: Use a different email service! Your "I tried to kill it with
> the above dot" and bullshit apology is worth zilch. A quick
> calculation shows that over the last month and a half, you have
> sent 76 or so emails to the list, all of which have contained your
> useless 663-byte corporate message, meaning you have sent 50K of spam
> to the list over that time period, which has been distributed to
> several thousand accounts by vger, resulting in probably over 100MB
> of spam over that time period. Fix it or use a different email account!
>
There is no other email service available to many people. They
have to use whatever their company provides. I can't even access yahoo
from inside the company. If the list keeper followed the recommended
email procedure of ignoring everything after a "." in the first
column, something that is as old as email itself, then there would
not be any of the crap that a lot of emailers append.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Fri, 16 Sep 2005 15:20:12 EDT, "linux-os (Dick Johnson)" said:
> from inside the company. If the list keeper followed the recommended
> email procedure of ignoring everything after a "." in the first
> column, something that is as old as email itself, then there would
> not be any of the crap that a lot of emailers append.
Actually, what RFC821 actually *said* clear back in August 1982 was:
4.5.2. TRANSPARENCY
Without some provision for data transparency the character
sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
by the user. In general, users are not aware of such
"forbidden" sequences. To allow all user composed text to be
transmitted transparently the following procedures are used.
1. Before sending a line of mail text the sender-SMTP checks
the first character of the line. If it is a period, one
additional period is inserted at the beginning of the line.
2. When a line of mail text is received by the receiver-SMTP
it checks the line. If the line is composed of a single
period it is the end of mail. If the first character is a
period and there are other characters on the line, the first
character is deleted.
I think you're confusing this with the behavior of the BSD 'mail' command,
which would treat a lone '.' as "end of message" *as part of the user interface*.
Apparently, at least one Unix vendor also shipped a brain-dead Sendmail that
was configured to *not* dot-stuff an SMTP connection by default.
In other words, if that '.' *ever* made the rest of the message dissapear, it
was due to either a *local* UI quirk or an outright *bug*.