I'm unsure about this usage of the timer (callout(?) )
how does the timer know which buffer pages to remove?
and if each userspace process does an ioctl to allocate a different buffer,
are
the new pages also visible to other processes?
Use mmap() we can ensure different process access differ
> I browsed kernel tree, I found those drivers which use contigmalloc() and
> contigfree() always call these two kernel interfaces in _attach() and
> _detach(), but in my driver, I call contigmalloc() in ioctl(), and call
> contigfree() in a callout function which is set by callout_reset().
>
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
> >Lot's of driver use file->private to get at per-device data easily,
> >but that's just a shortcut.
>
> Ok, I thought that you were talking about per-process data being in the
> file descriptor.
Can't be done.
FWIW, the main differenc
On Mon, Jun 13, 2005 at 08:59:17PM +0100, Christoph Hellwig wrote:
> disk drivers use a completely different set of entry points in Linux,
> and don't have access to per-fd data even in the case they're opened
> from userland. Character drivers to which this applies OTOH always
> get a valid struc
On Mon, Jun 13, 2005 at 12:54:40PM -0700, Julian Elischer wrote:
> though, some people use it for that purpose (e.g. in the original posting).
driver writers do all kinds of odd things ;-)
> it might not be such a bad idea..
> I don't see why the device entrypoints shouldn't have that argument
>
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
Lot's of driver use file->private to get at per-device data easily,
but that's just a shortcut.
Ok, I thought that you were talking about per-process data being in the
file descriptor.
No, L
Scott Long wrote:
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote:
Several times in the past we've seen people complainign that Linux
allows a device driver to know
who called it and somehow it seems to store somewhere some
information about who
op
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
Lot's of driver use file->private to get at per-device data easily,
but that's just a shortcut.
Ok, I thought that you were talking about per-process data being in the
file descriptor.
No, Linux has absol
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote:
> >Lot's of driver use file->private to get at per-device data easily,
> >but that's just a shortcut.
>
> Ok, I thought that you were talking about per-process data being in the
> file descriptor.
No, Linux has absolutely no concept of p
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote:
How does linux handle the implications of fork(2) in this scenario?
it's still counted as the same instance. Similar for dup or passing
descriptors over AF_UNIX sockets. The data is explictly not per-proce
On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote:
> How does linux handle the implications of fork(2) in this scenario?
it's still counted as the same instance. Similar for dup or passing
descriptors over AF_UNIX sockets. The data is explictly not per-process
but per instance.
There's
Christoph Hellwig wrote:
On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote:
Several times in the past we've seen people complainign that Linux
allows a device driver to know
who called it and somehow it seems to store somewhere some information
about who
openned the device.. tho
On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote:
>
> Several times in the past we've seen people complainign that Linux
> allows a device driver to know
> who called it and somehow it seems to store somewhere some information
> about who
> openned the device.. thos somehow allows
2nd try to answer this..
Apache Xie wrote:
I have some experiences in writing Linux device driver,
but I am new to FreeBSD kernel, although from the first
glimpse, there seems no big differences between the kernel
operations a char device driver can use, but I met some
problems when the driver
Daniel Eischen wrote:
On Mon, 13 Jun 2005, Julian Elischer wrote:
Maybe I don't understand the problem but..
I think the problem is that you want to keep a separate buffer for each
user,
while the drivers you are looking at expect to have only one buffer per
device.
One answer to this
On Mon, 13 Jun 2005, Julian Elischer wrote:
>
> Maybe I don't understand the problem but..
>
> I think the problem is that you want to keep a separate buffer for each
> user, ]
> while the drivers you are looking at expect to have only one buffer per
> device.
>
> One answer to this would be to mak
Apache Xie wrote:
I have some experiences in writing Linux device driver,
but I am new to FreeBSD kernel, although from the first
glimpse, there seems no big differences between the kernel
operations a char device driver can use, but I met some
problems when the driver is running in FreeBSD.
From: Mark Tinguely <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], freebsd-hackers@freebsd.org
Subject: Re: contigmalloc() and mmap()
Date: Mon, 13 Jun 2005 07:41:33 -0500 (CDT)
> I browsed kernel tree, I found those drivers which use contigmalloc()
and
> contigfree() always ca
I have some experiences in writing Linux device driver,
but I am new to FreeBSD kernel, although from the first
glimpse, there seems no big differences between the kernel
operations a char device driver can use, but I met some
problems when the driver is running in FreeBSD.
Our device is an exper
hi
i have a buffer obtained from contigmalloc. now i want to mmap it to
user space. i have done this in linux but unfortunately i am a freebsd
newbie. i read the code and it appeared that the device mmap routine is
passed an offset and it has to return the physical page frame no so that
the neces
20 matches
Mail list logo
