Andrew Morton <[email protected]> wrote:
> llseek takes a loff_t and file->f_pos is loff_t. I guess it's a bit moot
> on such a CPU. Was it deliberate?
It compiles with no error and no warning, so I haven't noticed. This is as
binfmt_elf.c is, I believe, so that is probably wrong too.
> (how come the kernel doesn't have a SEEK_SET #define?)
I don't know. It probably should.
> Three callsites - seems too large to inline.
Again taken from binfmt_elf.c, although I added the debugging stuff. It
shouldn't matter as the compiler will make its own decision (or does "inline"
get #defined to always-inline nowadays?).
> Which seems reasonable to me. I'll steal it from them.
Okay.
> Embedding returns and gotos in macros is evil. For new code it's worth
> doing it vaguely tastefully.
Again, stolen verbatim from binfmt_elf.c. I'd prefer to keep it comparable by
the blink-comparator method if possible.
> Does this need locking?
It shouldn't do; we own our own vma chain, and because we're part of exec, we
have a fresh mm_struct to play with. The VMAs themselves aren't allowed to
change, not even on NOMMU.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
