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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:35 EST