Syslinux - May 2014 - [PATCH 2/2] core/fs: Add support for Unix File system 1/2.

On 05/29/2014 07:36 AM, Raphael S Carvalho wrote:
> On Thu, May 29, 2014 at 11:30 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
>> On 05/29/2014 07:20 AM, Raphael S.Carvalho wrote:
>>> +static int ufs_readlink(struct inode *inode, char *buf)
>>> +{
>>> +    ufs_debug("ufs_readlink\n");
>>> +    return inode->size;
>>> +}
>>
>> Something missing here?
> Yes, implementation. It's just a placeholder until I implement it. You
> can see that I didn't even set it into fs_ops. At that time, I think
> Matt removed it himself as compiler complained about it being unused.
>>
Yes, it did.  However, it would be better to implement it.  As far as I
know, UFS symlinks are very similar to ext* symlinks (not surprising
since ext2 was heavily inspired by UFS): symlinks below a specific size
is stored in the inode overlaying the block pointers, and otherwise the
symlink is just an ordinary file.

	-hpa

On Thu, May 29, 2014 at 11:40 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
> On 05/29/2014 07:36 AM, Raphael S Carvalho wrote:
>> On Thu, May 29, 2014 at 11:30 AM, H. Peter Anvin <hpa at
zytor.com> wrote:
>>> On 05/29/2014 07:20 AM, Raphael S.Carvalho wrote:
>>>> +static int ufs_readlink(struct inode *inode, char *buf)
>>>> +{
>>>> +    ufs_debug("ufs_readlink\n");
>>>> +    return inode->size;
>>>> +}
>>>
>>> Something missing here?
>> Yes, implementation. It's just a placeholder until I implement it.
You
>> can see that I didn't even set it into fs_ops. At that time, I
think
>> Matt removed it himself as compiler complained about it being unused.
>>>
>
> Yes, it did.  However, it would be better to implement it.  As far as I
> know, UFS symlinks are very similar to ext* symlinks (not surprising
> since ext2 was heavily inspired by UFS): symlinks below a specific size
> is stored in the inode overlaying the block pointers, and otherwise the
> symlink is just an ordinary file.
I initially thought that readlink was intended for hard link, don't we
support them? But then it occurred to me that readlink is, of course,
intended for symlinks.
Don't you think the series could be merged as it-is? I will work on
ufs_readlink at this weekend, and as you mentioned, it shouldn't take
that long as ext2 could be used as a reference. I would love to see
the series merged as it has been around for months :-)
>
>         -hpa
>
>


-- 
Raphael S. Carvalho

On 05/29/2014 07:49 AM, Raphael S Carvalho wrote:
> On Thu, May 29, 2014 at 11:40 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
>>
>> Yes, it did.  However, it would be better to implement it.  As far as I
>> know, UFS symlinks are very similar to ext* symlinks (not surprising
>> since ext2 was heavily inspired by UFS): symlinks below a specific size
>> is stored in the inode overlaying the block pointers, and otherwise the
>> symlink is just an ordinary file.
> I initially thought that readlink was intended for hard link, don't we
> support them? But then it occurred to me that readlink is, of course,
> intended for symlinks.
> Don't you think the series could be merged as it-is? I will work on
> ufs_readlink at this weekend, and as you mentioned, it shouldn't take
> that long as ext2 could be used as a reference. I would love to see
> the series merged as it has been around for months :-)
I don't want to merge an under-development feature this late in the
release cycle.  In fact, if someone would be willing to write up the
release notes for 6.03 we are very close to be able to cut a 6.03
release, but I will have no time to do *anything* for quite a few days.
 I'm hoping I'll have time to sleep.

	-hpa

On Thu, May 29, 2014 at 11:40 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
> On 05/29/2014 07:36 AM, Raphael S Carvalho wrote:
>> On Thu, May 29, 2014 at 11:30 AM, H. Peter Anvin <hpa at
zytor.com> wrote:
>>> On 05/29/2014 07:20 AM, Raphael S.Carvalho wrote:
>>>> +static int ufs_readlink(struct inode *inode, char *buf)
>>>> +{
>>>> +    ufs_debug("ufs_readlink\n");
>>>> +    return inode->size;
>>>> +}
>>>
>>> Something missing here?
>> Yes, implementation. It's just a placeholder until I implement it.
You
>> can see that I didn't even set it into fs_ops. At that time, I
think
>> Matt removed it himself as compiler complained about it being unused.
>>>
>
> Yes, it did.  However, it would be better to implement it.  As far as I
> know, UFS symlinks are very similar to ext* symlinks (not surprising
> since ext2 was heavily inspired by UFS): symlinks below a specific size
> is stored in the inode overlaying the block pointers, and otherwise the
> symlink is just an ordinary file.
According to the ufs1/2 specification, a symbolic link stores the path
of the destination file in a fragment (1024 bytes), or in the 60/120
bytes used for ufs1/2 block pointers respectively.
>
>         -hpa
>
>


-- 
Raphael S. Carvalho

On 05/29/2014 08:29 AM, Raphael S Carvalho wrote:
> On Thu, May 29, 2014 at 11:40 AM, H. Peter Anvin <hpa at zytor.com>
wrote:
>> On 05/29/2014 07:36 AM, Raphael S Carvalho wrote:
>>> On Thu, May 29, 2014 at 11:30 AM, H. Peter Anvin <hpa at
zytor.com> wrote:
>>>> On 05/29/2014 07:20 AM, Raphael S.Carvalho wrote:
>>>>> +static int ufs_readlink(struct inode *inode, char *buf)
>>>>> +{
>>>>> +    ufs_debug("ufs_readlink\n");
>>>>> +    return inode->size;
>>>>> +}
>>>>
>>>> Something missing here?
>>> Yes, implementation. It's just a placeholder until I implement
it. You
>>> can see that I didn't even set it into fs_ops. At that time, I
think
>>> Matt removed it himself as compiler complained about it being
unused.
>>>>
>>
>> Yes, it did.  However, it would be better to implement it.  As far as I
>> know, UFS symlinks are very similar to ext* symlinks (not surprising
>> since ext2 was heavily inspired by UFS): symlinks below a specific size
>> is stored in the inode overlaying the block pointers, and otherwise the
>> symlink is just an ordinary file.
> According to the ufs1/2 specification, a symbolic link stores the path
> of the destination file in a fragment (1024 bytes), or in the 60/120
> bytes used for ufs1/2 block pointers respectively.
Right... the former is the same thing as a (short) file, right?  (I'm
assuming a very long symlink could be longer than 1024 bytes, too.)

	-hpa