[PATCH] VFS KPI/API versioning

View: New views
4 Messages — Rating Filter:   Alert me  

[PATCH] VFS KPI/API versioning

by Attilio Rao-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Often I found as it would have been useful to verify, mostly at
run-time, of a feature of the VFS was supported and I quickly thought
that having a run-time check for VFS versioning would not be a bad
idea.
In order to do that, I made the following patch:
http://www.freebsd.org/~attilio/vfs_modload.diff

which basically builds the vfs layer as a module adding a version
number that can be checked for filesystems/modules willing to load in
order to see if a specific feature is supported. Obviously I didn't
add an entry in the modules/ neither possibility to unload/shutdown
the module because we would not be willing to have such operations (or
a run-time load of the vfs).

Something that concerned me is also the mis-usage of the VFS_VERSION
macro, which can be easilly used at compile time in order to determine
if a feature is present or not. Basically, I have no idea by when it
doesn't get updated and if it has ever been checked in our codes. It
seems to use a random number as the start count, while it could have
been handled differently. Maybe it would be the case to start taking
care of that too, which can be an interesting tool.

Can you comment on the patch?
If you think it is a good idea I will commit right away on -CURRENT
and STABLE_8.

Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."

Re: [PATCH] VFS KPI/API versioning

by Peter Pentchev :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sat, Aug 29, 2009 at 04:04:55AM +0200, Attilio Rao wrote:
[snip]
> Something that concerned me is also the mis-usage of the VFS_VERSION
> macro, which can be easilly used at compile time in order to determine
> if a feature is present or not. Basically, I have no idea by when it
> doesn't get updated and if it has ever been checked in our codes. It
> seems to use a random number as the start count, while it could have
> been handled differently. Maybe it would be the case to start taking
> care of that too, which can be an interesting tool.

Quite offtopic, just a note about the "random number as the start count"
part - it's not exactly random; take a "fgrep 1966" to calendar.freebsd ;)

G'luck,
Peter

--
Peter Pentchev roam@...    roam@...    roam@...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This would easier understand fewer had omitted.


attachment0 (203 bytes) Download Attachment

Re: [PATCH] VFS KPI/API versioning

by Alexander Kabaev-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The patch looks simple enough and I think is a good idea. As for
VFS_VERSION, I am yet to see the evidence of it ever being used by
anybody.

--
Alexander Kabaev


signature.asc (195 bytes) Download Attachment

Re: [PATCH] VFS KPI/API versioning

by John Baldwin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Friday 28 August 2009 10:04:55 pm Attilio Rao wrote:
> Often I found as it would have been useful to verify, mostly at
> run-time, of a feature of the VFS was supported and I quickly thought
> that having a run-time check for VFS versioning would not be a bad
> idea.
> In order to do that, I made the following patch:
> http://www.freebsd.org/~attilio/vfs_modload.diff

You don't have to have an actual DECLARE_MODULE() to use MODULE_VERSION().  
Given that, you can simplify this patch down to a single line that just adds
the MODULE_VERSION().

--
John Baldwin
_______________________________________________
freebsd-arch@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@..."