Messages in this thread | | | Date | Thu, 17 Oct 2002 12:54:49 -0400 | From | Jeff Garzik <> | Subject | Re: [PATCH] Device-mapper submission 6/7 |
| |
Joe Thornber wrote: > The thing I'm not sure about is how to map the supend/resume semantics > onto the fs. It is tempting to bind suspend to an writeable open of > the TABLE file, and resume to the closing of the device. However that > means that closing the device both indicates the end of the table and > a resume, I'm not sure that is good enough, eg, if the table is bogus > we don't neccessarily want to automatically resume the old table. So > this leads us to start thinking about a sepearate SUSPENDED file that > we write a 1 or 0 to, yuck.
A popular way which also resolves atomicity issues is to just have a 'control' file, to which you write(2) a command code and command-specific data, and read(2) results of the operation (if any). This would allow you to do a new-table command, a suspend command, a resume-with-existing-table command, a resume-with-new-table command, etc. In other words, a more flexible ioctl(2) ;-)
Preferred method of data input is always ASCII, but if that is unreasonable, make sure your binary data is fixed-endian and fixed-size on all architectures.
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |