Ongoing virtio document prettification

On Mon, 25 Nov 2013 21:40:19 +0200 "Michael S. Tsirkin" <> wrote:
> On Mon, Nov 25, 2013 at 09:25:55PM +0200, Michael S. Tsirkin wrote: >
> On Mon, Nov 25, 2013 at 07:50:16PM +0100, Cornelia Huck wrote: > >
> On Mon, 25 Nov 2013 17:24:20 +0100 > >
> Cornelia Huck <> wrote: > > >  > > >
> FWIW, my ongoing work on the virtio document is sitting on github: > > > >  > > >
>  https://github.com/cohuck/virtio-spec.git  prettify > > > >  > > > > (branch will be rebased) > > >  > >
> I've tried to find out how to work with the predefined environments in > >
> command-{pdf,html}.tex for the bit definitions etc., but could not find > >
> a good way. The current topmost commit converts the status bit > >
> definitions to a tabularx, which is the version I currently like best. > >  >
> Pls make sure they look ok in HTML too though. >
> Not complaining as I didn't check myself, just reminding.  This one looked decent in html. The other tabulars with vertical lines are missing them in html, though; not sure what happened there.  > >  > >
> Might be a model for the feature bit lists. Feedback welcome. > >  >
> Something like description might be a good fit too. >
> This is what Rusty used originally. >
> So I would let him decide. >
> In fact you can get some of the goodies for free simply by >
> getting the old lyx from git and exporting to xetex from there.  Ah, I had not thought of the old lyx document, but that's a good idea.  > >  >
> Beats writing it from scratch manually. >
> E.g. it had: > egin{description}
> item [{ACKNOWLEDGE~(1)}] Indicates that the guest OS has found the
> device
> and recognized it as a valid virtio device.
> item [{DRIVER~(2)}] Indicates that the guest OS knows how to drive the
> device. Under Linux, drivers can be loadable modules so there may
> be a significant (or infinite) delay before setting this bit.
> item [{DRIVER\_OK~(4)}] Indicates that the driver is set up and ready
> to drive the device.
> item [{FAILED~(128)}] Indicates that something went wrong in the guest,
> and it has given up on the device. This could be an internal error,
> or the driver didn't like the device for some reason, or even a fatal
> error during device operation. The device must be reset before
> attempting
> to re-initialize.
> end{description}
>  I'll try this.