Home
last modified time | relevance | path

Searched hist:"70 d586c091f4e0f2c27e1b183310da49bbbc185b" (Results 1 – 2 of 2) sorted by relevance

/freebsd/sbin/mdconfig/
H A DMakefilediff 70d586c091f4e0f2c27e1b183310da49bbbc185b Thu Dec 28 21:57:57 CET 2000 Poul-Henning Kamp <phk@FreeBSD.org> Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
70d586c091f4e0f2c27e1b183310da49bbbc185b Thu Dec 28 21:57:57 CET 2000 Poul-Henning Kamp <phk@FreeBSD.org> Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
H A Dmdconfig.cdiff 70d586c091f4e0f2c27e1b183310da49bbbc185b Thu Dec 28 21:57:57 CET 2000 Poul-Henning Kamp <phk@FreeBSD.org> Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.
70d586c091f4e0f2c27e1b183310da49bbbc185b Thu Dec 28 21:57:57 CET 2000 Poul-Henning Kamp <phk@FreeBSD.org> Preliminary scaffolding for the new integrated vn+md device driver.

I decided to work on the md(4) driver and integrate the vn(4)
functionality into it mainly based on the name being more suitable.
Ideally 'vd' as in "virtual disk" would probably be the most logical
but our sound-master pointed out that this would cause uncontrollable
fits of giggles in the brits. Another complication would the needed
changes to the ramdisk boot/root functionality.

The vn driver will stay around for some time after I complete this
merge for transition reasons, and I'll make it whine to people that
they should migrate to the md(4) driver for some time before it
dies.

The kernel part of the new md(4) driver will be committed after more
testing.