Recently I've had to do some low-level surgery on some disks that have gone
bad in order to recover some of the data.
This has required me to zero out blocks on disk, patch up the affected
files, and pull the data off the disks.
I was toying around the with fsdb tool, but couldn't figure out a way
Hi hackers:
Today I had a need to run ggate over an IPv6-only network. I was a
little surprised that it didn't seem to like that, but not discouraged.
So here's a patch that adds IPv6 support for ggated(8) and ggatec(8)
;)
Overview:
* Standardizes on sockaddr_storage for both sockets and addres
In message: <[EMAIL PROTECTED]>
Dinesh Nair <[EMAIL PROTECTED]> writes:
: the userland application uses pthreads, and works like a charm both on 4.x
: and 5.x without using the device. however, when the device is used, it
: somehow has synchronization errors on 4.x, leading to timers
On Thu, Oct 27, 2005 at 05:14:51AM -0700,
[EMAIL PROTECTED] wrote:
> At 04:54 AM 10/27/2005 -0700, kamal kc wrote:
> | hello everybody,
> |
> | i am new to kernel programming.
> | i am developing a compression/decompression
> | functionality in the ip layer.
> |
> | i want to compile the k
On Thursday 27 October 2005 18:10, Bill Studenmund wrote:
> On Thu, Oct 27, 2005 at 09:29:52AM +0200, [EMAIL PROTECTED]
wrote:
> > On Wed, Oct 26, 2005 at 05:48:06PM -0700, Bill Studenmund wrote:
> > > The reason I'm interested in locators is so that if devices renumber
> > > themselves, the permi
Bill Studenmund wrote this message on Wed, Oct 26, 2005 at 10:22 -0700:
> On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote:
> >
> > Main features:
> >
> > - Implements FreeBSD's devfs on NetBSD.
>
> In the past, we (NetBSD folks) have talked about a devfs. One issue that
> ha
On 10/27/05 22:00 Scott Long said the following:
are doing. Other than that, there likely isn't anything that you need
to do for 'locking' in 4.x. The kernel is non-reentrant there, so you
don't need to worry about synchronizing multiple threads.
thanx a bunch, scott. it's been a nightmare t
M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: > carrying on this discussion, what would be a good locking mechanism to
: > use to protect tsleep() and other sensitive areas in a driver in freebsd
: > 4.x ?
:
On October 26, 2005 10:22 am, Bill Studenmund wrote:
> On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote:
> > Main features:
> > - Implements FreeBSD's devfs on NetBSD.
> In the past, we (NetBSD folks) have talked about a devfs. One issue
> that has come up (I'll be honest, I've
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: > carrying on this discussion, what would be a good locking mechanism to
: > use to protect tsleep() and other sensitive areas in a driver in freebsd
: > 4.x ?
: >
: > the current code
In message: <[EMAIL PROTECTED]>
Daniel Rudy <[EMAIL PROTECTED]> writes:
: I analyzed the source code for devinfo(8) and used as an example of how
: to use the devinfo(3) library. So I knew it transversed the device tree
: once, and my code does it twice, first time to locate (is it the
Xin LI <[EMAIL PROTECTED]> writes:
> When we were trying to make a userland FS application we have
> encountered "Invalid Argument" when doing mmap() over an open
> descriptor to a disk device.
It is not currently possible to mmap disk devices.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
Dinesh Nair wrote:
carrying on this discussion, what would be a good locking mechanism to
use to protect tsleep() and other sensitive areas in a driver in freebsd
4.x ?
the current code for the driver in 5.x uses mtx_lock and mtx_unlock with
some parts even being protected by mtx_lock(&Gian
Dinesh Nair wrote:
On 10/27/05 04:16 Scott Long said the following:
an example would be using
(BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which
would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is
that
0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore,
BUS_DMASYNC_POS
On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote:
>
> Main features:
>
> - Implements FreeBSD's devfs on NetBSD.
In the past, we (NetBSD folks) have talked about a devfs. One issue that
has come up (I'll be honest, I've raised it a lot) is a desire to retain
permission chang
On Oct 26, 2005, at 10:22 AM, Bill Studenmund wrote:
In the past, we (NetBSD folks) have talked about a devfs. One issue
that
has come up (I'll be honest, I've raised it a lot) is a desire to
retain
permission changes across boots, and to tie devices (when possible)
to a
device-specific a
On Thu, 27 Oct 2005 04:54:10 -0700 (PDT)
kamal kc <[EMAIL PROTECTED]> wrote:
> hello everybody,
>
> i am new to kernel programming.
> i am developing a compression/decompression
> functionality in the ip layer.
>
> i want to compile the kernel faster.
>
> it would
> be ok if the kernel doesn't
I'm trying to hack the ICC 8 port files to work with ICC 9 and I was
wondering if anyone knows right off the bat whether or not I can use
the existing patch files in the "files/" directory? I did some diffs on
the newer files and it looks like they should work okay, but I don't
know what effect tha
In message <[EMAIL PROTECTED]>, Jason Thorpe
writes:
>
>FWIW, I think a devfs based on our new tmpfs would be better for NetBSD.
>
I was under the impression that each i-node in tmpfs consumed a fair
amount of space, making it a bad match for things like /dev which have
very many i-nodes but n
At 04:54 AM 10/27/2005 -0700, kamal kc wrote:
| hello everybody,
|
| i am new to kernel programming.
| i am developing a compression/decompression
| functionality in the ip layer.
|
| i want to compile the kernel faster.
|
| it would
| be ok if the kernel doesn't have support for sound
| device
hello everybody,
i am new to kernel programming.
i am developing a compression/decompression
functionality in the ip layer.
i want to compile the kernel faster.
it would
be ok if the kernel doesn't have support for sound
devices, or other devices like scsi,usb etc. because
i would be using the
carrying on this discussion, what would be a good locking mechanism to use
to protect tsleep() and other sensitive areas in a driver in freebsd 4.x ?
the current code for the driver in 5.x uses mtx_lock and mtx_unlock with
some parts even being protected by mtx_lock(&Giant).
would the use o
22 matches
Mail list logo