[Vm-dev] Adding new primitives to FilePlugin
Mariano Martinez Peck
marianopeck at gmail.com
Fri Sep 23 18:51:18 UTC 2016
On Fri, Sep 23, 2016 at 2:04 PM, Eliot Miranda <eliot.miranda at gmail.com>
> Hi Holger,
> On Fri, Sep 23, 2016 at 6:29 AM, Holger Freyther <holger at freyther.de>
>> > On 23 Sep 2016, at 14:40, David T. Lewis <lewis at mail.msen.com> wrote:
>> > I suggest that you try this first by making your own plugin separate
>> from FilePlugin.
>> > If the idea proves useful in a general way, then consider adding it to
>> > FilePlugin is one of a small number of essential plugins that needs to
>> be implemented
>> > when bringing up a VM an a new platform, so it is generally a good idea
>> to resist
>> > the temptation to add features there.
>> Fair enough but the other plugin would need to have access to struct
>> and without plugin dependencies and ABI versioning doing it in another
>> looks rather fragile.
>> fdopen is not in C99 but the other primitive does not add burden on
>> porting as
>> a valid FILE* ptr is passed in and used. No additional API calls are
>> made. Any
>> objection to this primitive?
> Not from me. Seems like a very good idea. Feel free to contribute an
> I think we should also provide a primitive that answers the file
> descriptor associated with the fileID.
Yes! I was thinking about this one too some hours ago. I workaround it (for
my usecase) because I FIRST got the FD (from pipe()) and then got the
fileID...so I could simply "remember it" at my side. But sure, getting the
fd from a fileID would be very nice to have too.
> We could also provide primitives that set and get the FILE * structure if
> the platform has something analogous. This pair of primitives could either
> fail if the platform fdoesn't use this (Windows) or degenerate to the file
> descriptor access primitives. What do you think?
> >> From your previous email regarding sqFileReadIntoAt(), I think that you
>> > already noticed some rather questionable features that have crept into
>> > plugin over the years ;-)
>> yes, the ungetc for stdio seems rather odd.
> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev