Re: [Xen-devel] [PATCH V5 2/7] libxl_read_file_contents: add new entry to read sysfs file

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 6/30/2015 at 05:08 PM, in message
<21906.23698.778991.627734@xxxxxxxxxxxxxxxxxxxxxxxx>, Ian Jackson
<Ian.Jackson@xxxxxxxxxxxxx> wrote: 
> Chun Yan Liu writes ("Re: [PATCH V5 2/7] libxl_read_file_contents: add new  
> entry to read sysfs file"): 
> > >>> On 6/29/2015 at 06:52 PM, in message 
> > <21905.9050.452111.208124@xxxxxxxxxxxxxxxxxxxxxxxx>, Ian Jackson 
> > <Ian.Jackson@xxxxxxxxxxxxx> wrote:  
> > > Chun Yan Liu writes ("Re: [PATCH V5 2/7] libxl_read_file_contents: add 
> > > new  
> > > But if we are intending to use this with sysfs files, where the  
> > > reported size is known to be wrong, it seems to me that we should be  
> > > more proactive. 
> >  
> > If only for sysfs files, the bigger size problem should never 
> > happens, since sysfs system is not like normal file system, user 
> > won't be able to change the size. 
> >  
> > Reference from following link: 
> > http://www.makelinux.net/books/lkd2/ch17lev1sec8 
>  
> I don't think that can be relied on as a guide to the future API. 
> Maybe sysfs will grow support for bigger files in the future.  (Also, 
> that is actually a description of the kernel internals, not of the 
> syscall API). 

Yes, that's about kernel internals. But syscall API will finally call
kernel implementation. From those description, we knows why
fstat always return size 4096 (on x86_64, although actual file
content length is less). And it's not possible the file is changed
into a bigger size during we are reading it. About whether it'll
be changed in future, really don't know.

As to adding a check, it's certainly OK. I can update.

Thanks,
Chunyan
 
>  
> Thanks, 
> Ian. 
>  
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel