From: "Salyzyn, Mark" <Mark_Salyzyn@adaptec.com>
To: "'linux-os (Dick Johnson)'" <linux-os@analogic.com>,
"'mokhtar'" <mbmessaoud@yahoo.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: RE: Communication between user process and kernel modules
Date: Fri, 18 Jan 2008 07:35:16 -0800 [thread overview]
Message-ID: <532ABFBDAAC3A34EB12EBA6CEC2838F4391E89EC@ADPE2K703.adaptec.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0801180954040.7389@chaos.analogic.com>
Other means of communications include sysfs and procfs. These have the advantage of supporting scripting and can survive ABI changes that can plague the other interfaces; but are meant for low-bandwidth or out-of-band configuration or simple status reporting.
Sincerely -- Mark Salyzyn
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of
> linux-os (Dick Johnson)
> Sent: Friday, January 18, 2008 9:59 AM
> To: mokhtar
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Communication between user process and kernel modules
>
>
> On Fri, 18 Jan 2008, mokhtar wrote:
>
> >
> > Hi
> >
> > What are the different solution to make a user process
> communicate with a
> > kernel modules?
> >
> > Whatis the the advantages and disadvanteges of each solutions ?
> >
>
> ioctl() is the universal Unix mechanism for control of drivers
> (modules). open(), close(), read(), write(), mmap() are the other
> common methods. Some drivers may use sockets for communications.
> I such a case, you use setsockopt() to change things.
>
> Drivers can signal user-space processes as well. Such programs
> use select() and poll().
>
> >
> > --
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29
> BogoMips).
> My book : http://www.AbominableFirebug.com/
> _
>
>
> ****************************************************************
> 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 DeliveryErrors@analogic.com - and destroy
> all copies of this information, including any attachments,
> without reading or disclosing them.
>
> Thank you.
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2008-01-18 15:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-18 6:36 mokhtar
2008-01-18 14:59 ` linux-os (Dick Johnson)
2008-01-18 15:35 ` Salyzyn, Mark [this message]
2008-01-22 11:12 ` mokhtar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=532ABFBDAAC3A34EB12EBA6CEC2838F4391E89EC@ADPE2K703.adaptec.com \
--to=mark_salyzyn@adaptec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=mbmessaoud@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®