[syslinux] [PATCH 2/2] core/fs: Add support for Unix File system 1/2.

[Raphael S Carvalho]

On Thu, May 29, 2014 at 12:31 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> 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.)
To be honest, I don't know, the spec says that the *path* of the
destination is stored there. I assume that the fragment is
specifically for cases where the length of the destination path is
greater than the available space in the blk pointers.
>
>         -hpa
>
>



-- 
Raphael S. Carvalho