[vbox-dev] Removing code only used by no longer supported hosts (was Opportunity to significantly shrink the vboxsf Linux driver)

[Hans de Goede]

Hi,

On 08-08-17 16:23, Hans de Goede wrote:
> Hi,
> 
> On 07/25/2017 11:06 AM, Michael Thayer wrote:
>  > 13.07.2017 16:42, Michael Thayer wrote:
>  >> 10.07.2017 12:29, Hans de Goede wrote:
>  >> [Patch to shared folder code proposed by Hans to reduce the line count
>  >> of the Linux driver.]
>  >>
>  >> I reviewed the patch and made a few changes.  Not yet tested on any
>  >> platform, but I am posting my adjusted version so that other people can
>  >> test, including on FreeBSD and Haiku which I cannot do easily.  Note
>  >> that this applies to the normal VirtualBox tree, not to the packaged
>  >> Linux driver.
>  > I redid the patch again, after realising that the non-physical-page path
>  > was for supporting VirtualBox 3.0 and older on the host, which we have
>  > not tested or supported for a long time.  Therefore
>  > VbglR0CanUsePhysPageList() could be removed altogether.
> Ok, so I assume that similar checks to use physical page-lists can
> be removed from vboxguest too ?
> 
> And talking about removing support for old features, are hosts
> without intel-vt or the amd equivalent still supported; if not then
> I think that vgdrvInitFixateGuestMappings can be removed ?
> 
> And what about vgdrvReportGuestInfo() can that be modified to
> simply always first call VMMDevReq_ReportGuestInfo2 and then
> VMMDevReq_ReportGuestInfo or are some of the paths checking for
> rc == VERR_NOT_SUPPORTED || rc == VERR_NOT_IMPLEMENTED still
> needed ?

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 ?

Regards,

Hans