headers
Bernd Walter | 1 Jul 2003 11:29
Picon

Re: API change for bus_dma

On Mon, Jun 30, 2003 at 10:03:46AM -0400, Andrew Gallatin wrote:
> The idea is that I want to establish a mapping that can be used many
> times without any driver or kernel attention.  I don't want to do
> anything in terms of a system call, or interrupt, etc, to sync the
> cache with the state of the DMA'ed page before a DMA read or after a DMA
> write.
> 
> For example, scatter gather mapping on alphas (if FreeBSD supported it
> for PCI devices) would be fine with me since its cache-coherent and
> doesn't require any ddi_dma_sync() operations.

What makes you shure about alpha dma to be cache-coherent?
I'm not shure that the current implementation of _bus_dmamap_sync()
without barriers is correct.

--

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso <at> bwct.de                                  info <at> bwct.de

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Andrew Gallatin | 1 Jul 2003 14:22

Re: API change for bus_dma


Bernd Walter writes:
 > On Mon, Jun 30, 2003 at 10:03:46AM -0400, Andrew Gallatin wrote:
 > > The idea is that I want to establish a mapping that can be used many
 > > times without any driver or kernel attention.  I don't want to do
 > > anything in terms of a system call, or interrupt, etc, to sync the
 > > cache with the state of the DMA'ed page before a DMA read or after a DMA
 > > write.
 > > 
 > > For example, scatter gather mapping on alphas (if FreeBSD supported it
 > > for PCI devices) would be fine with me since its cache-coherent and
 > > doesn't require any ddi_dma_sync() operations.
 > 
 > What makes you shure about alpha dma to be cache-coherent?

7 years of sometimes painful experience with Myrinet on alpha ;)

 > I'm not shure that the current implementation of _bus_dmamap_sync()
 > without barriers is correct.

Barriers, if present, would be used to flush write buffers in the CPU
so they're seen by the cache, not to flush the cache itself.  I agree they
should be present.

Drew

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
David O'Brien | 3 Jul 2003 05:15
Picon
Favicon

Re: Unmounting by filesystem ID

On Sat, Jun 28, 2003 at 10:54:04PM +0100, Ian Dowse wrote:
> The patch below adds a new mount flag MNT_BYFSID that can be used
> to unmount a filesystem by specifying its filesystem ID instead of
> a path. The umount utility is changed to use this mechanism by
> default. This approach has a number of advantages:
> 
> - It avoids any lookup operations that could potentially block
>   forever, so filesystems such as NFS can be reliably unmounted
>   even if the server is not responding but looking up the root node
>   would require an RPC (maybe to an underlying filesystem).

VERY nice.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Daniel C. Sobral | 3 Jul 2003 20:11
Picon

Re: Unmounting by filesystem ID

Ian Dowse wrote:
> The patch below adds a new mount flag MNT_BYFSID that can be used
> to unmount a filesystem by specifying its filesystem ID instead of
> a path. The umount utility is changed to use this mechanism by
> default. This approach has a number of advantages:
> 
> - It avoids any lookup operations that could potentially block
>   forever, so filesystems such as NFS can be reliably unmounted
>   even if the server is not responding but looking up the root node
>   would require an RPC (maybe to an underlying filesystem).
> - The filesystem specification is unambiguous, so umount(8) can
>   be sure that it is unmounting the correct filesystem (more
>   work in umount(8) may be required here).
> - Detached filesystems can be unmounted. If a filesystem becomes
>   detached from the filesystem hierarchy because the underlying
>   filesystem got unmounted, it does not require a reboot to unmount
>   it.
> 
> Since unmounting by a path name is now only required for compatibility,
> in that case unmount() now just does a string comparison to find
> the correct filesystem. Also, this patch only affects unmounting;
> a similar approach could be applied to MNT_UPDATE mount operations.
> 
> I would like to commit this during the next few days. Any comments
> or suggestions?

Just in the unlikely case no one has said this to your face yet, man, 
you rule.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Kranzel | 5 Jul 2003 02:39

Re: Unmounting by filesystem ID

<snip Really Cool Stuff>

This is *way* cool. I use an NFS server a lot here, but the silly thing has hardware problems and crashes all
the time, then has to fsck its raid array, making it take forever to come back up. Being able to just unmount
the FS and keep working will be *very* useful.

 -Adam
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Vladimir B. Grebenschikov | 5 Jul 2003 15:57
Picon

Re: Unmounting by filesystem ID

В Sun, 29.06.2003, в 01:54, Ian Dowse пишет:
> The patch below adds a new mount flag MNT_BYFSID that can be used
> to unmount a filesystem by specifying its filesystem ID instead of
> a path. The umount utility is changed to use this mechanism by
> default. This approach has a number of advantages:

Cool!

May be you fix issue of umounting by known vnode ?
problem is in mounting different devices under chroot.
in list of mounts they differ only by device id, and it is rather 
difficult to umount filesystem if I known absolute path but do not enter
to chroot.

--

-- 
Vladimir B. Grebenschikov <vova <at> fbsd.ru>
SWsoft Inc.
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |
headers
Ian Dowse | 5 Jul 2003 17:05
Picon
Picon
Favicon

Re: Unmounting by filesystem ID

In message <1057413470.716.3.camel <at> localhost>, "Vladimir B. Grebenschikov" writ
es:
>May be you fix issue of umounting by known vnode ?
>problem is in mounting different devices under chroot.
>in list of mounts they differ only by device id, and it is rather=20
>difficult to umount filesystem if I known absolute path but do not enter
>to chroot.

The MNT_BYFSID approach makes it always possible to indicate to the
kernel which filesystem is to be unmounted, but some more work is
needed in the umount(8) utility to handle unusual cases.

The simplest way for umount to reliably pick the right file system
would be to have it call statfs(2) on the supplied path, and then
use the resulting filesystem ID to do the unmount(2) call. That
would allow you to unmount a filesystem that was mounted from within
a chroot by just specifying the full path to the filesystem even
though it is not the path that df or mount show.

Unfortunately, statfs(2) may get stuck if the path leads to (or
traverses) a network filesystem that is not responding. In this
case it is better for the umount utility to use getfsstat(2) with
the MNT_NOWAIT flag, and pick the filesystem that has the path that
was specified. This will do the wrong thing if for example you two
/var filesystems listed because one was mounted from inside a chroot.
There is also the problem of checking that the path points to the
root of the filesystem as statfs(2) works on any file or directory.

I think umount can probably be made do something reasonable in most
cases by having it use extra mechanisms such as statfs(2) only when
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Nelson | 5 Jul 2003 19:25
Gravatar

Re: Unmounting by filesystem ID

In the last episode (Jul 05), Ian Dowse said:
> In message <1057413470.716.3.camel <at> localhost>, "Vladimir B. Grebenschikov" writes:
> >May be you fix issue of umounting by known vnode ? problem is in
> >mounting different devices under chroot. in list of mounts they
> >differ only by device id, and it is rather=20 difficult to umount
> >filesystem if I known absolute path but do not enter to chroot.
> 
> The MNT_BYFSID approach makes it always possible to indicate to the
> kernel which filesystem is to be unmounted, but some more work is
> needed in the umount(8) utility to handle unusual cases.

Can mount(8) be changed to print the fsid?   Maybe hide it under -v if
it's a long value?  This seems like the only solution that can cover
the case where you have stacked two identical NFS mounts, one on top of
the other.  I've done this occasionally to force the kernel to retry
access to a server that has just come back after a reboot.

amd could probably benefit from dismounting using fsid if possible,
too.  Although it'd have to try fsid then path for the case where root
has dismounted then remounted one of its filesystems behind its back
(I've done this too, to change nfsv2 mounts to v3, etc).

--

-- 
	Dan Nelson
	dnelson <at> allantgroup.com
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
John-Mark Gurney | 7 Jul 2003 09:16
Favicon

usb module orginization

I would like to move the usb modules into a subdir like the many
other "groups" of modules already in the tree.  (i2c, digi, geom,
netgraph, to name a few)

i.e. modules/usb/ucom, modules/usb/usb, modules/usb/aue etc.

Comments?

--

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 12 comments |
headers
Bruce Evans | 7 Jul 2003 12:24
Picon

Re: usb module orginization

On Mon, 7 Jul 2003, John-Mark Gurney wrote:

> I would like to move the usb modules into a subdir like the many
> other "groups" of modules already in the tree.  (i2c, digi, geom,
> netgraph, to name a few)
>
> i.e. modules/usb/ucom, modules/usb/usb, modules/usb/aue etc.

This would be bug-for-bug compatible with the i2c, digi, geom,
netgraph groups of modules to name a few.  Don't forget to put
the installed modules in subdirs so that they are hard to find too.

Bruce
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |

Gmane