lkml.org 
[lkml]   [2002]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.069 / U:7.596 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site