Re: [platform-update-dev] Help wanted ...

[David Goodenough <david.goodenough@xxxxxxxxxxxxx>]

On Thursday 07 March 2002 14:39, you wrote:
> On Thursday 07 March 2002 14:20, klicnik@xxxxxxxxxx wrote:
> > David, thank you for the offer [sorry if you are getting this twice, I
> > wanted to make sure you get this and was not certain if you subscribe to
> > the mailing list ... in the future I will only post the mailing list].
> >
> > I am going to show my ignorance of native things in general, and Linux
> > native things in particular, by admitting in a very public forum that I
> > do not know the answer to your question (after all, this is why we are
> > asking for help). What I would ideally like to end up with, is a single
> > native implementation for each of the platforms that would work "out of
> > the box" on all the "variants" of each OS  without the need to upgrade
> > the base OS support or install some additional support. On Linux, this
> > would mean working against some common set of library calls that are
> > supported "out of the box" in the runtime libraries provided on both
> > targeted
> > distributions (SuSE 7.3, the RH version that will be supported by Eclipse
> > will likely end up being RH7.1 or later, rather than 7.2 as stated in my
> > original note).
> >
> > I do not know if this is possible. If not (eg. if we want to exploit some
> > particular support not available everywhere) we could handle this, but
> > would require multiple native library builds, and Eclipse started with
> > command-line options identifying the specific runtime environment (-os/
> > -arch flags).
> >
> > So are the libraries required to implement the interface we sketched out
> > available in both the RH and SuSE distributions "out of the box" and is
> > it possible to end up with one implementation that handles both
> > environments [sorry for turning the question around but we'll have to
> > work out the answer based on what is possible].
> >
> > > I would be happy to help.  I can cover Linux.  I have Redhat,
> > > Suse and Debian available.  More important however than particular
> > > distributions, is library requirements.
> > >
> > > Regards
> > >
> > > David
> > > _______________________________________________
> > > platform-update-dev mailing list
> > > platform-update-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/platform-update-dev
>
> That really should not be a problem, and the code should be compilable
> on any Linux platform, although quite what a CD-ROM looks like under
> Linux/390 I do not know.  Most of the dependancies etc are sorted out
> by autoconf and automake, the the C/C++ plugin for Eclipse knows all about
> those and will generate an appropriate stream.
>
> Do you have any of these written?  I looked in 0305 and found the
> Java code, do you have the platform code for any of the platforms yet?
>
> David
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-update-dev

There are three methods needed:-

int getFreeSpace( File path);
String getLabel( String path);
int getType( File path);

Well the first question is what is going to be passed as the path.  Ignoring
for the moment why one takes a String and the other two Files, what is this
path going to represent.  Is it the logical path (/mnt/cdrom) or the physical
path (/dev/hdb).  It should not matter greatly, but it would be nice to know.

getFreeSpace is relatively easy.  statfs will return the freespace from a 
path, so scale that to kilobytes (do you mean kilobytes or kebibytes?, I 
suspect the latter as ISO define kilo to mean 1000 and kebi to mean 1024).

getLabel is a little more difficult, as there appears to be no direct API
for getting the label, rather one has to read from an absolute position on
the drive.  This works fine for ISO9660 formatted CDs, but not all CDs are
ISO9660 formatted.  Do you only want it to work with ISO9660 media, if not
you will need to list the other formats you want to work.  I think, but do
not know, that DVDs will work as CDs in this respect, but what of CDs that
are formatted as EXT2 or FAT or whatever (which is quite possible and legal).
However that said, getting the label is only a few lines of code for ISO9660.

getType is all together more problematic.  WINE ducks the issue, and does it
according to the type specified in their configuration table.   VOLUME_FIXED
and VOLUME_REMOVABLE are probably not too difficult, but VOLUME_REMOTE is
well nigh impossible.  It is possible to detect that a mount point is mounted
using a known file system which is remote, such as SAMBA, NFS, AFS, but as 
far as I am aware there is no bit that says this is a remote file system.
The problem here is that we would fail to detect unknown remote file systems
as remote.  Is this a problem?  What is this information being used for?

David