Re: [RFC] persistent store

[Alan Cox]

> > "reader" which iterates over all records currently in the
> > store - returning type, size and a record identifier as
> > well as the actual data.
> > 
> > "writer" which writes a record with a type to the persistent store
> 
> I think it is necessary to require this to be NMI safe (in comments?),
> because hardware error handler may need to write to persistent storage
> in NMI context. Or we can add a "flag" field to let storage provider
> advocate its capability of NMI safe.

One thing we need for some of the driver code sitting in the pending pile
is support for hardware assisted logging, where record numberes are handed
out by a device register access.

> > The "type" of error record I mentioned earlier is used to
> > name the files ... saved console logs from kmsg_dmp() are
> > named with a "dmesg" prefix as shown above.
> > 
> > Once an error record has been viewed, analysed, saved. The
> > user can request it to be cleared by writing its name to the
> > "erase" file:

How will fragmentation be handled ?

> The persistent storage may be full, and the writing may fail. So I think
> we can just try to write one by one, until the first success writing.

If you intend to treat it basically like an fs why not just make it a
file system. No more weird echo erase into magic sysfs file node you can
just use "rm".

The logging off an interrupt isn't a big problem either as you can have a
pool of blocks which are preallocated for the log files and more can be
stitched into the files asynchronously after the interrupt logging
events. For that matter you can keep it as a circular log just easily but
present it as a file system.

> [...]
> > + * Erase records by writing their filename to the "erase" file. E.g.
> > + *     # echo "dmesg-0" > erase

rm dmesg-0

We have a model for this and filesystem indirected via sysfs commands is
in the daft category.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/