From: matthias.bgg@googlemail.com (Matthias Brugger)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Regarding Linux device driver Project
Date: Sun, 23 Jan 2011 18:30:07 +0100 [thread overview]
Message-ID: <4D3C659F.60200@gmail.com> (raw)
In-Reply-To: <COL116-W3B5A5C3381B016315F33582F80@phx.gbl>
Hi,
ashutosh mishra schrieb:
>> hi
>> i want to write a driver for DIO-48S PCI Card
>> (its automation Project - Aluminium Foil Winding Automated System Using PCI Interface)
>> i want to ask that what are the..prerequesite...for the Project...
>> i hav konwledge of C,89c51 Microcontroller,Arm Processor.........
>> but i am not able to start...........i hav gonr through Kernelnewbies at kernelnewbies.org Collected lots of information.
>> so please ...any one can help...????????
>> its Urgent Require.....
have a look on http://lwn.net/Kernel/LDD3/ especially chapter 12 should help you.
Regrads,
Matthias
>
> Thanks anr Regard ,
> Ashutosh
>
>
>
>> From: kernelnewbies-request at kernelnewbies.org
>> Subject: Kernelnewbies Digest, Vol 2, Issue 50
>> To: kernelnewbies at kernelnewbies.org
>> Date: Thu, 20 Jan 2011 12:00:01 -0500
>>
>> Send Kernelnewbies mailing list submissions to
>> kernelnewbies at kernelnewbies.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> or, via email, send a message with subject or body 'help' to
>> kernelnewbies-request at kernelnewbies.org
>>
>> You can reach the person managing the list at
>> kernelnewbies-owner at kernelnewbies.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Kernelnewbies digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Running kmemleak without sysfs support (Daniel Baluta)
>> 2. Re: possible regression? (Mag Gam)
>> 3. Re: possible regression? (Greg Freemyer)
>> 4. Re: Regarding Kernel Project (Greg KH)
>> 5. Re: Running kmemleak without sysfs support (Greg KH)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 20 Jan 2011 14:33:36 +0200
>> From: Daniel Baluta <daniel.baluta@gmail.com>
>> Subject: Re: Running kmemleak without sysfs support
>> To: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: kernelnewbies at kernelnewbies.org
>> Message-ID:
>> <AANLkTi=mEiha0rBOrX05xR=Ry5-otsB9faC29RZK7K4a@mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Thu, Jan 20, 2011 at 12:52 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> On Thu, 2011-01-20 at 10:41 +0000, Daniel Baluta wrote:
>>>> Can I make any use of kmemcheck if I don't have sysfs
>>>> kernel support enabled?
>>> Kmemleak can scan output the memory and report the number of leaked
>>> objects but if you need to get additional information about the leaked
>>> objects (like backtrace), you need debugfs enabled.
>> How is this reporting done? It will appear in dmesg output?
>>
>>> DEBUG_FS doesn't seem to be dependent on SYSFS but I never tried to
>>> enable one without the other (you might be able to mount the DEBUG_FS
>>> somewhere other than /sys/kernel/debug/).
>> I see. I was using 2.6.32 where it seems that debugfs depended on sysfs.
>> Decoupling was done some time later [1].
>>
>> thanks,
>> Daniel.
>>
>> [1] http://kerneltrap.org/mailarchive/linux-kernel/2010/8/5/4603446
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 20 Jan 2011 07:50:38 -0500
>> From: Mag Gam <magawake@gmail.com>
>> Subject: Re: possible regression?
>> To: Mulyadi Santosa <mulyadi.santosa@gmail.com>
>> Cc: Kernelnewbies at kernelnewbies.org
>> Message-ID:
>> <AANLkTiks-aBqGcYFBUyZ=LDGJsTNFOhTdie60O8aCS7i@mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> I am using RHEL 5.1. Sorry for not being clear.
>>
>> I wil give this a try today when I go back to class. But I was just
>> curious why this was happening. How would one disable "block merge"
>> efficiency? Has this feature been added recently?
>>
>> On Thu, Jan 20, 2011 at 12:28 AM, Mulyadi Santosa
>> <mulyadi.santosa@gmail.com> wrote:
>>> Hi...
>>>
>>> On Thu, Jan 20, 2011 at 10:36, Mag Gam <magawake@gmail.com> wrote:
>>>> Running on Redhat 5.1 if I do,
>>> Are you sure you're using that archaic distro? Or are you talking
>>> about RHEL 5.1?
>>>
>>>> dd bs=1024 count=1000000 if=/dev/zero of=/dev/null
>>>>
>>>> I get around 30Gb/sec
>>> Hm, mine is:
>>> $ dd bs=1024 count=1000000 if=/dev/zero of=/dev/null
>>> 1000000+0 records in
>>> 1000000+0 records out
>>> 1024000000 bytes (1.0 GB) copied, 1.12169 seconds, 913 MB/s
>>>
>>> This is on 2.6.36 SMP kernel compiled with gcc version 4.1.2 20080704
>>> (Red Hat 4.1.2-48).
>>>
>>>> However, when I do this with 2.6.37 I get close to 5GB/sec
>>> what if you use another blocksize, let's say 4K or even 32K? here's
>>> mine (again):
>>> $ dd bs=4K count=1000000 if=/dev/zero of=/dev/null
>>> 1000000+0 records in
>>> 1000000+0 records out
>>> 4096000000 bytes (4.1 GB) copied, 1.31167 seconds, 3.1 GB/s
>>>
>>> $ dd bs=32K count=1000000 if=/dev/zero of=/dev/null
>>> 1000000+0 records in
>>> 1000000+0 records out
>>> 32768000000 bytes (33 GB) copied, 4.91775 seconds, 6.7 GB/s
>>>
>>> see the difference?
>>>
>>> IMHO it's a matter of what I call "block merge efficiency"....the more
>>> you stuff pages (that fits into a "magic" number), the faster I/O you
>>> got.
>>>
>>> --
>>> regards,
>>>
>>> Mulyadi Santosa
>>> Freelance Linux trainer and consultant
>>>
>>> blog: the-hydra.blogspot.com
>>> training: mulyaditraining.blogspot.com
>>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 20 Jan 2011 09:29:20 -0500
>> From: Greg Freemyer <greg.freemyer@gmail.com>
>> Subject: Re: possible regression?
>> To: Mulyadi Santosa <mulyadi.santosa@gmail.com>
>> Cc: Kernelnewbies at kernelnewbies.org, Mag Gam <magawake@gmail.com>
>> Message-ID:
>> <AANLkTinkqXqYU8MVYma=5Zo2_gTZ61ZGKn+x+_zT6AeM@mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Mulyadi,
>>
>> You disappoint me. ;(
>>
>> Just kidding, but discussing dd throughput without the
>> "conv=fdatasync" parameter is just a waste of everyone's time.
>>
>> And Mag, use a big enough count that it at least takes a few seconds
>> to complete. A tenth of a second or less is just way to short to use
>> as a benchmark.
>>
>> Greg
>>
>> On Thu, Jan 20, 2011 at 12:28 AM, Mulyadi Santosa
>> <mulyadi.santosa@gmail.com> wrote:
>>> Hi...
>>>
>>> On Thu, Jan 20, 2011 at 10:36, Mag Gam <magawake@gmail.com> wrote:
>>>> Running on Redhat 5.1 if I do,
>>> Are you sure you're using that archaic distro? Or are you talking
>>> about RHEL 5.1?
>>>
>>>> dd bs=1024 count=1000000 if=/dev/zero of=/dev/null
>>>>
>>>> I get around 30Gb/sec
>>> Hm, mine is:
>>> $ dd bs=1024 count=1000000 if=/dev/zero of=/dev/null
>>> 1000000+0 records in
>>> 1000000+0 records out
>>> 1024000000 bytes (1.0 GB) copied, 1.12169 seconds, 913 MB/s
>>>
>>> This is on 2.6.36 SMP kernel compiled with gcc version 4.1.2 20080704
>>> (Red Hat 4.1.2-48).
>>>
>>>> However, when I do this with 2.6.37 I get close to 5GB/sec
>>> what if you use another blocksize, let's say 4K or even 32K? here's
>>> mine (again):
>>> $ dd bs=4K count=1000000 if=/dev/zero of=/dev/null
>>> 1000000+0 records in
>>> 1000000+0 records out
>>> 4096000000 bytes (4.1 GB) copied, 1.31167 seconds, 3.1 GB/s
>>>
>>> $ dd bs=32K count=1000000 if=/dev/zero of=/dev/null
>>> 1000000+0 records in
>>> 1000000+0 records out
>>> 32768000000 bytes (33 GB) copied, 4.91775 seconds, 6.7 GB/s
>>>
>>> see the difference?
>>>
>>> IMHO it's a matter of what I call "block merge efficiency"....the more
>>> you stuff pages (that fits into a "magic" number), the faster I/O you
>>> got.
>>>
>>> --
>>> regards,
>>>
>>> Mulyadi Santosa
>>> Freelance Linux trainer and consultant
>>>
>>> blog: the-hydra.blogspot.com
>>> training: mulyaditraining.blogspot.com
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>
>>
>> --
>> Greg Freemyer
>> Head of EDD Tape Extraction and Processing team
>> Litigation Triage Solutions Specialist
>> http://www.linkedin.com/in/gregfreemyer
>> CNN/TruTV Aired Forensic Imaging Demo -
>> ?? http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/
>>
>> The Norcross Group
>> The Intersection of Evidence & Technology
>> http://www.norcrossgroup.com
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 20 Jan 2011 07:12:27 -0800
>> From: Greg KH <greg@kroah.com>
>> Subject: Re: Regarding Kernel Project
>> To: Mulyadi Santosa <mulyadi.santosa@gmail.com>
>> Cc: kernelnewbies <Kernelnewbies@kernelnewbies.org>
>> Message-ID: <20110120151227.GA12768@kroah.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Thu, Jan 20, 2011 at 12:32:39PM +0700, Mulyadi Santosa wrote:
>>> On Thu, Jan 20, 2011 at 10:01, Greg KH <greg@kroah.com> wrote:
>>>> On Wed, Jan 19, 2011 at 09:11:53PM -0500, Pein Junior wrote:
>>>>>
>>>>>> What is the USB device and vendor id?
>>>>> Hope this manual help explaining all that.
>>> Guys, I don't wanna ruin your discussion, but don't you think it's OOT
>>> now? or are we going to rename this list as chitchat at vger.org?
>> This is how you both solve bugs, and learn about solving them yourself.
>>
>> I'll be glad to take this to the linux-usb or linux-kernel lists, as
>> this type of conversation is quite common there, so why wouldn't it also
>> be common here?
>>
>> If it's annoying you, I suggest getting a better email client, one that
>> lets you mark any thread as "ignored" so we don't bother you.
>>
>> best of luck,
>>
>> greg k-h
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 20 Jan 2011 07:56:57 -0800
>> From: Greg KH <greg@kroah.com>
>> Subject: Re: Running kmemleak without sysfs support
>> To: Daniel Baluta <daniel.baluta@gmail.com>
>> Cc: catalin.marinas at arm.com, kernelnewbies at kernelnewbies.org
>> Message-ID: <20110120155657.GA29375@kroah.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Thu, Jan 20, 2011 at 12:41:57PM +0200, Daniel Baluta wrote:
>>> Hello all,
>>>
>>> Can I make any use of kmemcheck if I don't have sysfs
>>> kernel support enabled?
>> Why would you ever want to run a kernel without sysfs support? If you
>> turn it off, you loose a _lot_ of functionality that you will need to
>> add back to your system in some other manner.
>>
>> What, specifically, is wrong with sysfs that is solved by turning it
>> off?
>>
>> thanks,
>>
>> greg k-h
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>> End of Kernelnewbies Digest, Vol 2, Issue 50
>> ********************************************
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2011-01-23 17:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1.1295542801.26950.kernelnewbies@kernelnewbies.org>
2011-01-21 6:37 ` Regarding Linux device driver Project ashutosh mishra
2011-01-23 17:30 ` Matthias Brugger [this message]
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=4D3C659F.60200@gmail.com \
--to=matthias.bgg@googlemail.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.