Re: /tmp as tmpfs and consequence for imaging software
On 15 November 2011 08:17, Neil Williams <email@example.com> wrote:
> On Tue, 15 Nov 2011 07:41:54 +0100
> Andrew Shadura <firstname.lastname@example.org> wrote:
>> On Mon, 14 Nov 2011 00:14:18 +0100
>> Josselin Mouette <email@example.com> wrote:
>> > > No it does not work like you said. We know the matrix structure, not
>> > > the kernel. We map and unmap manually. Doing as you said is
>> > > inneficient and trash a lot cache and so on.
>> > This is getting insane. Please learn how to use madvise and
>> > posix_fadvise and let the kernel deal with paging. The kernel knows
>> > everything about the underlying hardware; the application does not.
>> And what about the software being cross-platform? What about other
>> systems which don't have such system calls?
> Ever heard of #ifdef #else #endif ?
> If similar calls exist, use them conditionally. Where they do not
> exist, you need to decide if that system can be supported and accept
> the limitations of doing so. Where the calls DO exist it is inexcusable
> NOT to use the support available.
> Do not cripple all platforms with the sins of the weakest.
I think this discussion needs a sanity check.
Please remember, the topic of conversation is whether an application
can reasonably make the assumption that the system defined tmp
directory is a suitable place to store temporary data.
You appear to be saying "Of course not; every application should
include a small compatibility layer to call the appropriate syscalls
or other relevant interface for every possible platform to indicate to
the kernel exactly what it wants to do with its data. Yes, that
doesn't answer the question of where temporary data should be stored
in the first place, but I don't care about that as long as nobody has
the audacity to suggest that maybe /tmp might be a reasonable place
for transient temporary data."
Can you see why this might be treated with incredulity? Maybe it's
worth going back to the topic at hand rather ranting about something