Linux-Development-Sys Digest #579, Volume #8     Tue, 20 Mar 01 17:13:21 EST

Contents:
  Re: copy_to_user() question ("Jim Fischer")
  Re: copy_to_user() question ("Jim Fischer")
  large pings with DF bits (sreangsu acharyya)
  Re: Writing a Device Driver ("Niels Sterrenburg")
  Re: File system driver questions. (Kasper Dupont)
  Re: request_irq RTC ... how does it work? (Kasper Dupont)
  Re: Anyone know about Aureal Semiconductor? ("Michael")
  Re: Process Scheduler/Resource Management (Kasper Dupont)
  Re: File system driver questions. (Dennis Jenkins)
  Re: Writing a Device Driver (Josef Allen)
  Re: Book suggestions ([EMAIL PROTECTED])
  Re: request_irq RTC ... how does it work? (Eric van der Velde)
  what type of data does /dev/mouse pass for alternate pointing device? ("Josh K.")
  Re: Writing a Device Driver (David Findlay)

----------------------------------------------------------------------------

From: "Jim Fischer" <[EMAIL PROTECTED]>
Subject: Re: copy_to_user() question
Date: Tue, 20 Mar 2001 00:43:19 -0800


"Kevin Buhr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...

> > I'm a newby kernel hacker who's unable to get the copy_to_user()
function to
> > write data from kernel space to user space.
>
> Actually, it *did* work.  You just checked for the wrong failure
> condition.

Kevin,

Thanks for the feedback. I understand your comments about the "zero good,
non-zero bad" idea on result codes, but the bottom line is the char buffer
up in the user-layer app is not being modified by the kernel-layer
copy_to_user() call. <?> Note that the user-layer buffer *is* being modified
correctly when I use the for() loop & put_user() code. I'm probably just
overlooking something "obvious."


Jim

P.S. For anyone who might be following this thread, I failed to mention in
my original post that I am in fact specifying the __SMP__ macro when
building the module for an SMP host, i.e.,

    gcc -O2 -DKERNEL -D__MODULE__ -D__SMP__ -Wall -Werror <etc> -c xyz.c





------------------------------

From: "Jim Fischer" <[EMAIL PROTECTED]>
Subject: Re: copy_to_user() question
Date: Tue, 20 Mar 2001 00:43:19 -0800


"Kevin Buhr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...

> > I'm a newby kernel hacker who's unable to get the copy_to_user()
function to
> > write data from kernel space to user space.
>
> Actually, it *did* work.  You just checked for the wrong failure
> condition.

Kevin,

Thanks for the feedback. I understand your comments about the "zero good,
non-zero bad" idea on result codes, but the bottom line is the char buffer
up in the user-layer app is not being modified by the kernel-layer
copy_to_user() call. <?> Note that the user-layer buffer *is* being modified
correctly when I use the for() loop & put_user() code. I'm probably just
overlooking something "obvious."


Jim

P.S. For anyone who might be following this thread, I failed to mention in
my original post that I am in fact specifying the __SMP__ macro when
building the module for an SMP host, i.e.,

    gcc -O2 -DKERNEL -D__MODULE__ -D__SMP__ -Wall -Werror <etc> -c xyz.c





------------------------------

From: [EMAIL PROTECTED] (sreangsu acharyya)
Subject: large pings with DF bits
Date: Tue, 20 Mar 2001 11:47:14 +0000 (UTC)

Hi,
  I want to ping a host with an unfragmented packet of size around ( 500
- 900 ) bytes. Linux's ping doesnt have an option to set the DF bit.  So
if i modify the source code of ping with appropriate setsockopt(), will
that suffice.

I ask this specifically because in the /usr/src/linux/ipv4/icmp.c the
function icmp_send( ) seems to be checking for sizes in excess of 576
and dropping the extra baggage. ( I am pretty much a newbie, havent
clocked more than a hour  eye-balling the kernel code...so I might be
wrong ).

 Does this piece of code get involved, when an userlevel program sends
ICMP packets ? I can always send with ping -s, but have a feeling that
these get passed along after fragmentation. BTW  the MTU is larger than
the size of the packet I want to send.

Help needed
-- sreangsu


-- 
Posted from geometric28.pune.gsslco.co.in [203.129.226.254] (may be forged) 
via Mailgate.ORG Server - http://www.Mailgate.ORG

------------------------------

From: "Niels Sterrenburg" <[EMAIL PROTECTED]>
Subject: Re: Writing a Device Driver
Date: Tue, 20 Mar 2001 15:35:37 +0100

I hope you get the information... but I'm afraid that they are like most
companies and that you only get in contact with sales persons(and they
really don't know anything offcourse).

Good luck



"David Findlay" <[EMAIL PROTECTED]> wrote in message
news:7jzt6.36860$[EMAIL PROTECTED]...
> I have email conexant telling them that I would like to write a Linux
> driver for the conexant HCF(controllerless) chipset for modems. I told
them
> I would be writing it under the gnu public license for hopeful inclusion
in
> the Linux kernel, and asked for a device driver kit to be emailed to me.
> What do you reckon my chances of getting the information I need are?
Thanks,
>
> David
>



------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: File system driver questions.
Date: Tue, 20 Mar 2001 15:12:45 +0000

Dennis Jenkins wrote:
> 
>        I wish to write a file system driver for the Apple II ProDOS file
> system.  I have the full specs on the file system, and I can write
> userland tools to copy files in/out of ProDOS disk images.  I'm fairly
> good at c/c++/asm.  However, the Linux kernel source code for file
> system drivers seems... a bit... dense.  I have no idea how where to
> start.  I want to write this thing incrementally, instead of writing it
> all at once, only to discover that it does not work.  Where are the
> online resources that would help me?
> 
>         I have read the source to the ROMFS driver and parts of the HFS
> driver.  In my first attempt, I hacked the hell out of the ROMFS
> driver.  I could register the prodos filesystem driver, but non of the
> operations worked.  Hell, they weren't even implemented, b/c I had no
> idea where to start!
> 
>         Thanks,

I cannot answer all your questions, but I have a few
hints which might make life easier for you.

Obviously you should start with a read only version,
this means less risk of damages and probably less
than half the work to do to get something working.

A good way to start probably is this order:
read_super which is present in struct file_system_type
read_inode which is present in struct super_operations
And then the readdir operation. With theese functions
correctly implemented you should be able to see the
contents of the root directory on the fs.

BTW are you writing for 2.2.x or 2.4.x? There are lots
of changes in the VFS. Since you probably want to
upgrade at some time and don't want to rewrite your
code you should consider using 2.4.x. I think writing
a FS for 2.4.x is simpler, but I never actually tried.

In 2.4.x there is a very simple example named ramfs,
just 8KB of source including all FS opperations.

> 
> --
> [EMAIL PROTECTED]                           Universal Savings Bank.
> 
> The three most dangerous things are a programmer with a soldering
> iron, a manager who codes, and a user who gets ideas.

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: request_irq RTC ... how does it work?
Date: Tue, 20 Mar 2001 15:21:42 +0000

Eric van der Velde wrote:
> 
> Hello,
> 
> I am having trouble to request an IRQ on the RTC. From a device I open
> /dev/rtc (using filp_open) and set the the RTC using ioctl the generate
> interrupts. (set the rate and enable the periodic interrupts)
> 
> The call request_irq call fails (-16). When I do a free_irq before the
> request_irq, it works, but then I cannot get an interrupt frequency
> higher than 64 Hz.

Only root is allowed to request more than 64Hz.
Notice that your code is opperating on behalf
of the current process, if you don't have
control over what is the current process you
should not use the ioctl, (and perhaps not
filp_open either).

Perhaps the solution is to use a daemon process,
but without knowing what you are trying to do
I cannot say for sure. You can start a daemon
within a module with kernel_thread() if you
really need to do so, but it might be hard to
unload such a module.

> 
> Question is how do I receive RTC interrupts within a module?
> 
> I think I should use the poll function on /dev/rtc, but how?
> 
> Regards Eric.

-- 
Kasper Dupont

------------------------------

From: "Michael" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Anyone know about Aureal Semiconductor?
Date: Tue, 20 Mar 2001 09:22:24 -0600

Try http://sourceforge.net/projects/aureal/
==================
"Ethan M. Schwartz" <[EMAIL PROTECTED]> wrote in message
news:9968jt$j1l$[EMAIL PROTECTED]...
> they went out of business a while ago...
>
> "Shekhar Patkar" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hi,
> >
> > Does anyone know what happened to Aureal Semiconductor? I
> > have an A3D card in my system, and the driver doesn't work
> > with kernel 2.4.2. I'm trying to fix it and have some problems,
> > but when I try to look for their web site, it looks like the
> > company has disappeared!
> >
> > Would appreciate any pointers ...
> > Thanks,
> > Shekhar
>
>



------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Process Scheduler/Resource Management
Date: Tue, 20 Mar 2001 15:38:41 +0000

[EMAIL PROTECTED] wrote:
> 
> Hi!
> 
> I just wonder if it is possible to limit a process to use
> X% of the availabe CPU time. With 'setrlimit' I am able
> to set the max. CPU time a process is allowed to use, but
> I want to say it relative...
> 
> Background: I have many long run processes (like a ftp-server)
> and I want to make sure that this NEVER consumes more than
> X% of the available CPU time.

I don't think it is possible to specify a percentage.
Instead try using the nice command, it can lower the
priority which means that if any higher priority jobs
run it will only get a very small percentage of the
CPU time.

> 
> Is that really impossible under Linux? Is there a better
> schedule-system available for Linux?

It is possible to change the source code and recompile
the kernel. I think Real Time Linux uses a modified
scheduler, though I haven't studied it, and I don't
know if it is the answer to your question.

> 
>   ++Viage
> 
> P.S.: BTW: Can I tell a process to use only CPU no. X and
> not one ot the other CPUs?

I don't think so, but I believe it will come some day.
It will be useful in particular in some parts of the
kernel which currently use some strange hacks to force
code onto the first CPU.

> 
> 
> 
> --
> Sent by tmphop  from hotmail subpart of com
> This is a spam protected message. Please answer with reference header.
> Posted via http://www.usenet-replayer.com/cgi/content/new

-- 
Kasper Dupont

------------------------------

From: Dennis Jenkins <[EMAIL PROTECTED]>
Subject: Re: File system driver questions.
Date: Tue, 20 Mar 2001 09:51:14 -0600

Kasper Dupont wrote:
> 
> Dennis Jenkins wrote:
> >
> >        I wish to write a file system driver for the Apple II ProDOS file
> > system.  I have the full specs on the file system, and I can write
> > userland tools to copy files in/out of ProDOS disk images.  I'm fairly
> > good at c/c++/asm.  However, the Linux kernel source code for file
> > system drivers seems... a bit... dense.  I have no idea how where to
> > start.  I want to write this thing incrementally, instead of writing it
> > all at once, only to discover that it does not work.  Where are the
> > online resources that would help me?
> >
> >         I have read the source to the ROMFS driver and parts of the HFS
> > driver.  In my first attempt, I hacked the hell out of the ROMFS
> > driver.  I could register the prodos filesystem driver, but non of the
> > operations worked.  Hell, they weren't even implemented, b/c I had no
> > idea where to start!
> >
> >         Thanks,
> 
> I cannot answer all your questions, but I have a few
> hints which might make life easier for you.
> 
> Obviously you should start with a read only version,
> this means less risk of damages and probably less
> than half the work to do to get something working.
> 
> A good way to start probably is this order:
> read_super which is present in struct file_system_type
> read_inode which is present in struct super_operations
> And then the readdir operation. With theese functions
> correctly implemented you should be able to see the
> contents of the root directory on the fs.
> 
> BTW are you writing for 2.2.x or 2.4.x? There are lots
> of changes in the VFS. Since you probably want to
> upgrade at some time and don't want to rewrite your
> code you should consider using 2.4.x. I think writing
> a FS for 2.4.x is simpler, but I never actually tried.
> 
> In 2.4.x there is a very simple example named ramfs,
> just 8KB of source including all FS opperations.

Thanks for the info.  I had planned on doing this on a Slackware 7
system, which runs a 2.2 kernel.  But I hope to have my code make it to
the real kernel someday, so I had better upgrade before I begin.

What kernel would be best to start with?

-- 
[EMAIL PROTECTED]                           Universal Savings Bank.

The three most dangerous things are a programmer with a soldering
iron, a manager who codes, and a user who gets ideas.

------------------------------

From: Josef Allen <[EMAIL PROTECTED]>
Subject: Re: Writing a Device Driver
Date: Tue, 20 Mar 2001 11:14:07 -0500

Mr Sterrenburg,
Where can I get a linux device driver tool kit 

Josef D. Allen

On Tue, 20 Mar 2001, Niels Sterrenburg wrote:

> I hope you get the information... but I'm afraid that they are like most
> companies and that you only get in contact with sales persons(and they
> really don't know anything offcourse).
> 
> Good luck
> 
> 
> 
> "David Findlay" <[EMAIL PROTECTED]> wrote in message
> news:7jzt6.36860$[EMAIL PROTECTED]...
> > I have email conexant telling them that I would like to write a Linux
> > driver for the conexant HCF(controllerless) chipset for modems. I told
> them
> > I would be writing it under the gnu public license for hopeful inclusion
> in
> > the Linux kernel, and asked for a device driver kit to be emailed to me.
> > What do you reckon my chances of getting the information I need are?
> Thanks,
> >
> > David
> >
> 
> 
> 
> 


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Book suggestions
Date: Tue, 20 Mar 2001 16:34:03 GMT

Arnaud Westenberg <[EMAIL PROTECTED]> wrote:
: I'm looking for a good Unix internals book. The things it should discuss
: at least are; processes, IPC, Kernel mechanisms, daemons!, drivers, etc.
: The daemons part is mandatory since this is the main reason I want the
: book. Maybe some network basics?

Advanced Programming in the Unix Environment, Stevens
Solaris Internals: Core Kernel Architecture, Mauro & McDougall
Design of the Unix Operating System, Bach
Linux Kernel Internals, Bar

-- 
    Jeff Gentry  [EMAIL PROTECTED]  [EMAIL PROTECTED]
           SEX           DRUGS           UNIX

------------------------------

From: Eric van der Velde <[EMAIL PROTECTED]>
Subject: Re: request_irq RTC ... how does it work?
Date: Tue, 20 Mar 2001 20:19:04 +0100

In article <[EMAIL PROTECTED]>,
 Kasper Dupont <[EMAIL PROTECTED]> wrote:

> Eric van der Velde wrote:
> > 
> > Hello,
> > 
> > I am having trouble to request an IRQ on the RTC. From a device I open
> > /dev/rtc (using filp_open) and set the the RTC using ioctl the generate
> > interrupts. (set the rate and enable the periodic interrupts)
> > 
> > The call request_irq call fails (-16). When I do a free_irq before the
> > request_irq, it works, but then I cannot get an interrupt frequency
> > higher than 64 Hz.
> 
> Only root is allowed to request more than 64Hz.
> Notice that your code is opperating on behalf
> of the current process, if you don't have
> control over what is the current process you
> should not use the ioctl, (and perhaps not
> filp_open either).
> 
> Perhaps the solution is to use a daemon process,
> but without knowing what you are trying to do
> I cannot say for sure. You can start a daemon
> within a module with kernel_thread() if you
> really need to do so, but it might be hard to
> unload such a module.
> 
> > 
> > Question is how do I receive RTC interrupts within a module?
> > 
> > I think I should use the poll function on /dev/rtc, but how?
> > 
> > Regards Eric.

Kasper,

Thanks for you reply. I think I have to explain a little bit more. 

I know that there are limitations to the RTC when loaded by Joe User, 
but root can configure the RTC up to 8192 Hz interruptrate. When I try 
to configure the RTC for an interrupt rate higher than 64 Hz, at the 
very first time (the first time after a system boot), I am able to set 
the frequency higher than 64 Hz, but after calling free_irq (removing 
the original interrupt service routine of the /dev/rtc device) I am not 
able to get a rate higher than 64 Hz.

What I really want to do drive some signal on the parallel port at a 
certain rate. Timing is VERY important!! I tried this using kernel 
timers, but their resolution is not high enough (100Hz for ix86). I need 
at least a 1 kHz resolution.

So I don't want to remove the original interrupt service routine 
anymore, but perhaps use the poll function which is available from the 
rtc device, but I do not know how?

I don't know what kernel_threads are and what they do, but with my 
knowledge of threads I think this would be ideal for me, because I need 
some 'infinite loop' in my kernel module, which can poll the rtc....


Please help me in this one.

Regards Eric van der Velde

------------------------------

From: "Josh K." <[EMAIL PROTECTED]>
Subject: what type of data does /dev/mouse pass for alternate pointing device?
Date: Tue, 20 Mar 2001 20:24:15 GMT

Hi,
    I wish to started a project using a VR device as a simple mouse pointer.
I was currious if anybody had any info regarding either changing gpm, or
pointing the X window system to another dev file for mouse pointer info.

where can I get info on how linux deals with mice and what type of data is
passed from the gpm app to the window system reading the dev file?  I have
enough info to take 3D points from the device but I do not know in what
presentation the standard mouse driver presents the X,Y points.  Any help
would be greatly apprciated.

Also any info on using the parport drivers now coming standard to many linux
distros for grabing signal of parallel port pins.

Thanks for any help you can provide, if this projects gets out the planning
stage just more cool stuff for the linux community to play with :-)

-Josh



------------------------------

From: David Findlay <[EMAIL PROTECTED]>
Subject: Re: Writing a Device Driver
Reply-To: [EMAIL PROTECTED]
Date: Wed, 21 Mar 2001 07:30:18 +1000

Niels Sterrenburg wrote:
> I hope you get the information... but I'm afraid that they are like most
> companies and that you only get in contact with sales persons(and they
> really don't know anything offcourse).
> 
> Good luck

I am starting to have some luck I think. They asked me for a mailing 
address.

David

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to