All of lore.kernel.org
 help / color / mirror / Atom feed
From: fordearlinux@gmail.com (Malice)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Writing a new device driver
Date: Tue, 26 Jun 2012 01:12:24 +0530	[thread overview]
Message-ID: <4FE8BF20.9050300@gmail.com> (raw)

Hi

I'm planning to write a new device driver on linux kernel . The device i 
intend to write will be a device that'll pipe the data coming into it to 
another computer that'll be also having the same device . So in short 
the device'll be readable/writable and should communicate through 
network . I know it sounds like a socket but the idea would be to 
implement a interface in shell so that if you type

|     root at host$echo "Hi">>mydevice
|

will transfer the word hi to the system on the other side of network 
(and may be configure it to store on file). This is a leisure time 
project i intend to do and it sounds much like sockets and other already 
existing implementations . Well the questions regarding the design for 
device implementations are : 1)Should i use a block or a character 
device . The advantage i see for a block device is that if i am a 
initiating a complete file transfer through the device(which i in tend 
to support later) , then it would be fast .

2)How do i write the data on the network . I'm familiar with sockets and 
stuff , but using sockets from with in the kernel has performance 
issues(I read it somewhere, after all sockets was desined to be used in 
userspace) . Will using netfilter or other stuffs work ?Maybe crafting 
the packet directly would help :-)? Any innovations are welcome

3)How do i configure the driver , like how do i let it know that it 
should connect to a specific host >in user space programs we usually do 
this by config files , but to change the connection settings of a driver 
how do you manage it ? (sysfs ?? Frankly i never worked with sysfs or 
proc/ )

4)Now as the design specifies all the transfer of files is in kernel 
space . When i transfer huge chunks of data through kernel space , will 
it slow down the system ?. The design shouldnt overload the system , 
doing it in a pre-empitble kernel will help, but are there other 
charecterstics i should be aware of to make the design as efficient as 
possible (i'm doing it on the latest linux kernel) ?

5)And i dont want to leave a huge memory imprint so is there any way i 
can reduce it while tranferring of data , may be cacheing data on disk ?

6)I will have to design a user space programme to co ordinate the driver 
wont i ? I cannot let the driver alone do the whole task , tat wud be 
tedious

Comments Welcome


I've also posted the same question at stackoverflow too
http://stackoverflow.com/questions/11167424/writing-a-new-device-driver

Regards
Malice

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120626/0e1bbe91/attachment.html 

             reply	other threads:[~2012-06-25 19:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25 19:42 Malice [this message]
2012-06-26  7:47 ` Writing a new device driver Matthias Brugger

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=4FE8BF20.9050300@gmail.com \
    --to=fordearlinux@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.