Hi,
On 25-08-17 10:29, Michael Thayer wrote:
Hello Hans,
21.08.2017 14:49, Hans de Goede wrote:
[...]
First of all thank you for the answers to the above questions (see
archives).
I've just found one more piece of code where I wonder if that should
be kept. VbglR0SfMapFolder first tries SHFL_FN_MAP_FOLDER and if thar
fails falls back to SHFL_FN_MAP_FOLDER_OLD. Are hosts only supporting
SHFL_FN_MAP_FOLDER_OLD still supported, or can the fallback path
be dropped ?
Ping? Getting an answer to this would be goold.
Likewise vfsmod.c has this:
if (info->nullchar != '\0'
|| info->signature[0] != VBSF_MOUNT_SIGNATURE_BYTE_0
|| info->signature[1] != VBSF_MOUNT_SIGNATURE_BYTE_1
|| info->signature[2] != VBSF_MOUNT_SIGNATURE_BYTE_2) {
/*
* An old version of mount.vboxsf made the syscall.
* Translate the old parameters to the new structure.
*/
struct vbsf_mount_info_old *info_old = (void *)info;
static struct vbsf_mount_info_new info_compat;
Is this support for older mount.vboxsf binaries still necessary ?
[...]
Back from holiday and trying to catch up on unread e-mail. From reading
the code, I would say that both of those can be removed. Did you test
it? Regarding supporting old versions of mount.vboxsf (which I would
have got rid of long ago anyway if I had found time: the module could
just as well do the parsing without a user-space helper), the only
reason for that I can think of is if one is downgrading the Additions,
presumably for testing purposes, and does not want to reboot to reload
the old kernel modules. Not really an argument for keeping that code
any more.
Ok, thank you for the feedback.
I've removed support for both old interfaces and things still work fine:
https://github.com/jwrdegoede/vboxsf/commit/e89091819397785f687185413919023aacf2253f
Regards,
Hans
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
