Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Yes, I think we've all agreed we can do it ... it's now a question of
> whether we can stomach the ick factor of actually initiating a
> transaction in close ... I'm still feeling queasy.

NFS does transactions - including figuring out if the data will fit - on
file close. It does that for real data so I'd relax. With hard disks we
don't even complete a set of actions on close they just float around for
a bit and get committed (but if there is a media failure you lose if you
didnt commit them first via fsync etc)

> The alternative might be a two file approach (either in sysfs or a mini
> custom fs), one for load up data and the other for initiate transaction
> with the data errors (like overflow) being returned on the load up file
> and the transaction errors being returned on the write that initiates
> the transaction.

The two file problem then turns into the "which transaction of the two
done in parallel" problem.

> My architectural sense is that transaction on close, provided we can
> make it a more universally accepted idea, has a lot of potential because
> it's more intuitive than the two file approach.

Agreed

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux