Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Matthew Dillon writes:
I think the biggest win in regards to being able to arbitrarily stack
devices is to NOT attempt to forward struct buf's between devices when
non-trivial manipulation is required, and instead to make
I think the biggest win in regards to being able to arbitrarily stack
devices is to NOT attempt to forward struct buf's between devices when
non-trivial manipulation is required, and instead to make struct buf's
cheap enough that a device can simply allocate a new one and copy the
In message [EMAIL PROTECTED], Matthew Dillon writes:
I think the biggest win in regards to being able to arbitrarily stack
devices is to NOT attempt to forward struct buf's between devices when
non-trivial manipulation is required, and instead to make struct buf's
cheap enough
Poul-Henning Kamp wrote:
http://phk.freebsd.dk/misc/b_iocmd.patch
I concur that these patches represent effectlively a mechanical
edit of the sources to produce effectively the same functionality
as before.
I have a couple of points which I would like to discuss.
These are not
In message [EMAIL PROTECTED], Julian Elischer writes:
1/ I think the removal of IPSEC from LINT is by mistake in this patch
yes, that is a mistake.
2/ The change of separating buffer management from IO management
is long overdue and the introduction of b_iocmd is a good first step
for this.
http://phk.freebsd.dk/misc/b_iocmd.patch
B_WRITE is bogusly defined as zero, which is a perfect candidate
for coding and logic mistakes, we saw the most recent victim of
this bogosity as recently as a few days ago.
This patch moves the "io-command" aspect of the b_flags into a new
It is most ironic that of course you were the loudest supporter of
SOS when he ripped out all my code that did EXACTLY all this.
(I might add that this was done without any warning to me. The
The commit messages being my first notice).
It was fully working and quite a few people were running it
Poul-Henning Kamp wrote:
This patch is the first step towards the stackable BIO system as
sketched out on http://www.freebsd.org/~phk/Geom/
you don't mention how you plan to get around the problem that
arbitrarily stacking devices means arbitrarily allocating minor
numbers. I used devfs to
It seems Julian Elischer wrote:
It is most ironic that of course you were the loudest supporter of
SOS when he ripped out all my code that did EXACTLY all this.
(I might add that this was done without any warning to me. The
The commit messages being my first notice).
It was fully working
This patch is the first step towards the stackable BIO system as
sketched out on http://www.freebsd.org/~phk/Geom/
Please test review.
There's no code to test- it's just a sketch. It's fine as a start, but it's
important that you clarify the role of node device drivers in informing the
On Mon, 13 Mar 2000, Matthew Jacob wrote:
This patch is the first step towards the stackable BIO system as
sketched out on http://www.freebsd.org/~phk/Geom/
Please test review.
{ as Poul reminded me, I missed the header line that had the patch - sorry
about that }
To
11 matches
Mail list logo
