[PATCH] nsswitch extensions + caching daemon
Hello! I've made the nsswitch + caching daemon project during the Google's Summer of Code. There were some issues, though, in the first release of the project. Here is the second version of the patch: http://www.rsu.ru/~bushman/nsswitch_cached/nss_cached.patch It contains several new features, which were not included in the first release (like negative caching, nscd-like functionality support, new cached.conf file syntax). Besides, a lot of code style improvements were made to match the style(9) rules. The description of the project itself and its new features can be found here: http://rsu.ru/~bushman/nsswitch_cached/ Please test the patch and send me your feedback. It would be just great if it could be included to the HEAD. If it's not possible right now, I'll continue working on it to fix all the issues, so that it could be finally merged into the FreeBSD source tree. With best regards, Michael Bushkov Rostov State University ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
correct use of bus_dmamap_sync
i came across this message
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.html
and while it explains the use of bus_dmamap_sync, i'm still a little
confused on it's usage. i'm trying to port over a driver from freebsd 5.x
to freebsd 4.x, and it uses dma mapped addresses extensively.
i've been trying to figure out the best places to use bus_dmamap_sync when
reading/writing to a dma mapped address space. however, i cant seem to get
the gist of this, either from the mailing list discussions or the man page.
i've got two buffers, one for read, and one for write. both have been set
up with calls to bus_dma_tag_create, bus_dmamem_alloc and bus_dmamap_load.
the buffers, which are used in the calls to bus_dmamem_alloc and
bus_dmamap_load are,
int *readbuf;
int *writebuf;
(must i malloc space for them before passing them into those functions, or
will the call to bus_dmamem_alloc do it for me ?)
also, i'm on FreeBSD 4.11 right now, and i notice the definitions of
BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x in
machine/bus_dma.h
the pseudo code for the read and write, called during an interrupt cycle, are:
rx_func()
{
POSITION A
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
}
tx_func()
{
POSITION C
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
}
the question is, what op should i use for bus_dmamap_sync in positions A,
B, C and D ?
any assistance would be gladly appreciated, as i'm seeing some really weird
symptoms on this device, where data written out is being immediately read
in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync().
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/25/05 21:15 Dinesh Nair said the following:
the pseudo code for the read and write, called during an interrupt
cycle, are:
rx_func()
{
POSITION A
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
}
tx_func()
{
POSITION C
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
}
the question is, what op should i use for bus_dmamap_sync in positions
A, B, C and D ?
responding to my own request, i mean which of BUS_DMASYNC_PREREAD,
BUS_DMASYNC_POSTREAD, BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE should i
use, and where ?
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo The opinions here in no way reflect the opinions of my $a $b. |
| done; done |
+=+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: correct use of bus_dmamap_sync
man bus_dma(9)
-Original Message-
From: Dinesh Nair [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 25, 2005 7:03 AM
To: Dinesh Nair
Cc: freebsd-hackers@freebsd.org
Subject: Re: correct use of bus_dmamap_sync
On 10/25/05 21:15 Dinesh Nair said the following:
the pseudo code for the read and write, called during an interrupt
cycle, are:
rx_func()
{
POSITION A
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
}
tx_func()
{
POSITION C
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
}
the question is, what op should i use for bus_dmamap_sync
in positions
A, B, C and D ?
responding to my own request, i mean which of
BUS_DMASYNC_PREREAD, BUS_DMASYNC_POSTREAD,
BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE should i use, and where ?
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==
==
+==+
| for a in past present future; do
|
| for b in clients employers associates relatives
neighbours pets; do |
| echo The opinions here in no way reflect the opinions of
my $a $b. |
| done; done
|
+=
==
+==+
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote:
i came across this message
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.htm
l
and while it explains the use of bus_dmamap_sync, i'm still a little
confused on it's usage. i'm trying to port over a driver from freebsd 5.x
to freebsd 4.x, and it uses dma mapped addresses extensively.
i've been trying to figure out the best places to use bus_dmamap_sync when
reading/writing to a dma mapped address space. however, i cant seem to get
the gist of this, either from the mailing list discussions or the man page.
i've got two buffers, one for read, and one for write. both have been set
up with calls to bus_dma_tag_create, bus_dmamem_alloc and bus_dmamap_load.
the buffers, which are used in the calls to bus_dmamem_alloc and
bus_dmamap_load are,
int *readbuf;
int *writebuf;
(must i malloc space for them before passing them into those functions, or
will the call to bus_dmamem_alloc do it for me ?)
bus_dmamem_alloc() will do it for you.
also, i'm on FreeBSD 4.11 right now, and i notice the definitions of
BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x in
machine/bus_dma.h
the pseudo code for the read and write, called during an interrupt cycle,
are:
rx_func()
{
POSITION A
bus_dmamap_sync(PREREAD);
while(there_is_some_data) {
memcpy(somebuf, readbuf)
}
POSITION B
bus_dmamap_sync(POSTREAD);
}
tx_func()
{
POSITION C
bus_dmamap_sync(PREWRITE);
while(there_is_some_data) {
memcpy(writebuf, somebuf)
}
POSITION D
bus_dmamap_sync(POSTWRITE);
}
the question is, what op should i use for bus_dmamap_sync in positions A,
B, C and D ?
any assistance would be gladly appreciated, as i'm seeing some really weird
symptoms on this device, where data written out is being immediately read
in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync().
Probably not as the sync()'s don't really do anything with memory allocated
via bus_dmamem_alloc(). The operations are named from the CPU's perspective,
thus when you send data to your device, that is a WRITE operation (even
though your device is doing a DMA to read data), and when you get data back
from your device, that is a READ operation (even though your device is doing
a DMA to write the data into the buffer).
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where to release proc.p_stats
On Friday 21 October 2005 06:04 pm, Julian Elischer wrote:
John Baldwin wrote:
On Friday 21 October 2005 04:32 pm, David Schultz wrote:
On Fri, Oct 21, 2005, John Baldwin wrote:
On Friday 21 October 2005 09:13 am, nocool wrote:
freebsd-hackers�ï�¼Œhello
Question about 5.4 kernel source code.
I have some question about strust proc's initialize. Kernel use
proc_zone to allocate proc items and initialize them with proc_init
(sys\kern\kern_proc.c) function. In this function, we can find the
field proc.p_stats is allocated with pstats_alloc(), as
p-p_stats = pstats_alloc();
and pstats_alloc is realized as
malloc(sizeof(struct pstats), M_SUBPROC, M_ZERO|M_WAITOK);
But I can't find where this field is freed. If it will not be release,
will there be memory leakage?
Heh, das@ forgot to call pstats_free() when he did the changes. The
reason is probably because proc_fini() doesn't do anything useful
because we never recycle proc structs. We should probably at least add
the operations there though for documentation purposes. Something like
this would work I think:
I didn't put in the call because we never free proc structures, but
documenting what should happen if we ever do free them is a good
idea. There's a fair amount of other cleanup that needs to happen
as well, which you can probably find in the CVS history. (IIRC,
I'm guilty of removing the code at a time when more things depended
upon struct proc being type safe. Are there any remaining reasons
why we can't free struct procs at this point?)
By the way, there's no reason why we can't fold struct pstats into
struct proc so we don't have to allocate and free it at all.
It's never shared, so the extra level of indirection just adds overhead.
The main reason I didn't make this change earlier was to maintain binary
compatibility when I backported my U-area changes to -STABLE.
Looks like some of the functions (vm_dispose_proc() and
sched_destroyproc()) have vanished, so this is all that would be in there
now:
Index: kern_proc.c
===
RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.232
diff -u -r1.232 kern_proc.c
--- kern_proc.c 2 Oct 2005 23:27:56 - 1.232
+++ kern_proc.c 21 Oct 2005 21:21:45 -
@@ -196,8 +196,17 @@
static void
proc_fini(void *mem, int size)
{
+#ifdef notnow
+ struct proc *p;
+ p = (struct proc *)mem;
+ pstats_free(p-p_stats);
+ ksegrp_free(FIRST_KSEGRP_IN_PROC(p));
+ thread_free(FIRST_THREAD_IN_PROC(p));
+ mtx_destroy(p-p_mtx);
+#else
panic(proc reclaimed);
+#endif
}
/*
sched_destroyproc was removed by someone I believe because it was not
used.
if you were removing a proc you possibly should re introduce it.
I actually looked in the CVS history to find out if vm_dispose_proc() and
sched_destroyproc() should come back and I don't think they need to.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devinfo(3) problem...
At about the time of 10/24/2005 7:28 AM, victor cruceru stated the following: Daniel, What is the OS version you are using when this is happening? Did you try to update the libdevinfo (using cvsup for example) to a newer version? I think that under the original 5.4 it is a bug in devinfo(4) with the described behaviour below. I'm running 5.4-RELEASE. When you mentioned that it might be a bug, I went and looked at /usr/src/lib/libdevinfo/devinfo.c using the cvs web depository. I found that devinfo_generation = 0 was added to the end of the devinfo_free function starting at line 367. I added the code and recompiled just that library, and now everything seems to be working ok, except now I'm getting a bunch of garbage on the serial number of the USB flash drive. I'm not sure if it's my code, or if it's a bug in the library. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/26/05 01:27 John Baldwin said the following: On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: (must i malloc space for them before passing them into those functions, or will the call to bus_dmamem_alloc do it for me ?) bus_dmamem_alloc() will do it for you. thanx. Probably not as the sync()'s don't really do anything with memory allocated via bus_dmamem_alloc(). The operations are named from the CPU's perspective, however, the man page at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion=0manpath=FreeBSD+5.4-stableformat=html says, Although no explicit loading is required to access the memory referenced by the returned map, the synchronization requirements as described in the bus_dmamap_sync() section still apply. also, is bus_dmamap_load() required, since the same man page section above says it isnt ? have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On 10/26/05 01:02 Singh, Vijay said the following: man bus_dma(9) thanx, but that doesn't exist on freebsd 4.x. though http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion=0manpath=FreeBSD+5.4-stableformat=html has it, it still applies only to 5.x. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devinfo(3) problem...
Hi Daniel, Yes, this is the fix. And yes, I think that the bug was reported (at least on a mailing list...) BTW: I dare to suggest to fully upgrade your system to the latest 6.0, it is a huge step forward from 5.4. Before doing this you may want to give it a try by booting from a CD and check that your hw is fully functional (and detected). To check if it is your mistake or another bug in libdevinfo, you may want to run the associated tool (man -k devinfo). Hope this helps. On 10/25/05, Daniel Rudy [EMAIL PROTECTED] wrote: At about the time of 10/24/2005 7:28 AM, victor cruceru stated the following: Daniel, What is the OS version you are using when this is happening? Did you try to update the libdevinfo (using cvsup for example) to a newer version? I think that under the original 5.4 it is a bug in devinfo(4) with the described behaviour below. I'm running 5.4-RELEASE. When you mentioned that it might be a bug, I went and looked at /usr/src/lib/libdevinfo/devinfo.c using the cvs web depository. I found that devinfo_generation = 0 was added to the end of the devinfo_free function starting at line 367. I added the code and recompiled just that library, and now everything seems to be working ok, except now I'm getting a bunch of garbage on the serial number of the USB flash drive. I'm not sure if it's my code, or if it's a bug in the library. -- Daniel Rudy -- victor cruceru Non est respondendum ad omnia. ( Cicero, Pro Murena Oratio ) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: On 10/26/05 01:27 John Baldwin said the following: On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: (must i malloc space for them before passing them into those functions, or will the call to bus_dmamem_alloc do it for me ?) bus_dmamem_alloc() will do it for you. thanx. Probably not as the sync()'s don't really do anything with memory allocated via bus_dmamem_alloc(). The operations are named from the CPU's perspective, however, the man page at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_syncapropos=0sektion= 0manpath=FreeBSD+5.4-stableformat=html says, Although no explicit loading is required to access the memory referenced by the returned map, the synchronization requirements as described in the bus_dmamap_sync() section still apply. Yes, and on some archs the sync() operations do have memory barriers in place, but there isn't any bounce buffering with bus_dmamem_alloc() memory. also, is bus_dmamap_load() required, since the same man page section above says it isnt ? Well, you need it to get the physical address to pass to your device for it to do DMA against. have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? I don't think so as far as the interface. thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. Yes, I know. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: correct use of bus_dmamap_sync
On Tue, Oct 25, 2005 at 04:10:52PM -0400, John Baldwin wrote: On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: [...] thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. Yes, I know. :) Please go read the HEAD version of the manpage; it's been fixed recently to improve the description of these details. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpN3gKadHm2L.pgp Description: PGP signature
[Fwd: Re: use of bus_dmamap_sync]
Apparently the original poster sent his question to me in private, then
sent it again to the mailing list right as I was responding in private.
Anyways, no need to continue to guess; if anyone has any questions, feel
free to ask.
Below is my response. Note that I edited it slightly to fix an error
that I found
Scott
Original Message
Subject: Re: use of bus_dmamap_sync
Date: Tue, 25 Oct 2005 07:59:03 -0600
From: Scott Long [EMAIL PROTECTED]
To: Dinesh Nair [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Dinesh Nair wrote:
hi scott,
i came across this message of yours,
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.html
and you seem like the perfect person to assist me in something. i've been
trying to figure out the best places to use bus_dmamap_sync when
reading/writing to a dma mapped address space. however, i cant seem to get
the gist of this, either from the mailing list discussions or the man page.
could you assist me ?
i'm on FreeBSD 4.11 right now, and i notice the definitions of
BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x.
this is what i have done. i have used two buffers to handle reads from the
device and writes to the device. the pseudocode is as follows
rx_func()
{
POSITION A
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD);
Ask hardware for data
bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD);
read from readbuf (i'm assuming that device has put data in
readbuf)
POSITION B
}
tx_func()
{
POSITION C
write to txbuf (here's where we write to txbuf)
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE);
notify hardware of the write
POSITION D
bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE);
}
what BUS_DMASYNC_{PRE,POST}{READ,WRITE} option should i use for
bus_dmamap_sync in position A, B, C and D ?
any assistance would be gladly appreciated, as i'm seeing some really weird
symptoms on this device, where data written out is being immediately read
in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync().
The point of the syncs is to do the proper memory barrier and cache
coherency magic between the CPU and the bus as well as do the memory
copies for bounce buffers. If you are dealing with statically mapped
buffers, i.e. for an rx/tx descriptor ring, then you'll want code
exactly like described above. In reality, most platforms only do stuff
for the POSTREAD and PREWRITE cases, but for the sake of completeness
the others are documented and usually used in drivers. NetBSD might
have platforms that require operations for PREREAD and POSTWRITE, but
I've never looked that closely.
If you are dealing with dynamic buffers,
i.e. for mbuf data, then you'll want the PREREAD and PREWRITE ops to
happen in the callback function for bus_dmamap_load() and the POSTREAD
and POSTWRITE ops to happen right before calling bus_dmamap_unload. So
in this case is would be:
rx_buf()
{
allocate buffer
allocate map
bus_dmamap_load(tag, map, buffer, size, rx_callback, arg, flags)
}
rx_callback(arg, segs, nsegs, errno)
{
convert segs to hardware format
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD)
notify hardware about buffer
}
rx_complete()
{
bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD)
bus_dmamap_unload(tag, map, buffer)
deallocate map
process buffer
}
tx_buf()
{
fill buffer
allocate map
bus_dmamap_load(tag, map, buffer, size, tx_callback, arg, flags)
}
tx_callback(arg, segs, nsegs, errno)
{
convert segs to hardware format
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE)
notify hardware about buffer
}
tx_complete()
bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE)
bus_dmamap_unload(tag, map, buffer)
deallocate map
free buffer
}
This is the design that busdma was originally modelled on. It works
well for storage devices where the load operation must succeed. It
doesn't work as well for network devices where the latency of the
indirect calls is measurable. So for that, I added
bus_dmamap_load_mbuf_sg(). It eliminates the callback function and
returns the scatter gather list directly. So, the above example would
be:
tx_buf()
{
bus_dma_segment_t segs[maxsegs];
int nsegs;
fill buffer
allocate map
bus_dmamap_load_mbuf_sg(tag, map, buffer, size, segs, nsegs)
convert segs to hardware format
bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE)
notify hardware about buffer
}
Also, the 'allocate map' part should be done carefully. Most network
drivers are lazy and call bus_dmamap_create() and bus_dmamap_destroy()
for each buffer. It's often better to pre-allocate the maps at init
time, put them on a list, and then just push and pop them off the list
at runtime. This is usually faster than calling the busdma
usb umass
que onda hola estoy inetentando montar my memoria usbcon usbdevs -v me aparece con el driver usb0 y cuando quiero montarla con mount_msdosfs /dev/usb1 /mnt/usb1 me mando un mensaje diciendo /dev/usb1 block device require _ Tu horóscopo diario, semanal y gratuito. [1]Cartas, tarot y predicciones en MSN Horóscopo References 1. http://g.msn.com/8HMBESES/2728??PS=47575 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
