on 05/04/2012 09:07 Pedro Giffuni said the following:
> Hi YongCon;
>
> The project would be very interesting for us. I am pretty sure you will
> not have problems finding a mentor.
>
> That said, let me point out an old thread:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/0425
Hi YongCon;
The project would be very interesting for us. I am pretty sure you will
not have problems finding a mentor.
That said, let me point out an old thread:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042565.html
I think the biggest problem is that you will have to get acq
cc hackers@
-- Forwarded message --
From: Yongcong Du
Date: Tue, Apr 3, 2012 at 1:23 AM
Subject: [gsoc2012] Port NetBSD's UDF implementation
To: a...@freebsd.org, netch...@freebsd.org
Hi Andriy and Alexander,
Firstly, let me introduce myself;) I'm a graduate st
e the attached patch, first hunk is just for consistency.
The code was borrowed from cd9660, only field/variable names are adjusted.
Just tested it with my shiny new Bluray drive, and it work wonders.
Finally seamless playback of media files off UDF carrying media.
So, how does it look WRT commi
Pav Lucistnik wrote:
Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
And while I have your attention, I have a related question.
I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
mkisofs, and when I mount the UDF part of them, the mount point (root
directory of media) have
on 28/02/2008 11:59 Pav Lucistnik said the following:
> Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
>
> And while I have your attention, I have a related question.
>
> I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
> mkisofs, and when I mount the UDF
Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
And while I have your attention, I have a related question.
I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
mkisofs, and when I mount the UDF part of them, the mount point (root
directory of media) have 0x000 permissions. Yes
>>> this was almost trivial :-)
>>> See the attached patch, first hunk is just for consistency.
>>> The code was borrowed from cd9660, only field/variable names are adjusted.
>
> Just tested it with my shiny new Bluray drive, and it work wonders.
> Finally seamle
ed patch, first hunk is just for consistency.
> > The code was borrowed from cd9660, only field/variable names are adjusted.
Just tested it with my shiny new Bluray drive, and it work wonders.
Finally seamless playback of media files off UDF carrying media.
So, how does it look WRT c
!
Me too.
Bruce, thank you for putting me back on the ground :-)
Even in UDF case, when we bread() via a file or directory vnode we pass
a logical 2048-byte block number (within the file) to bread(). In this
case the code in getblk() does the right thing when it calculates offset
as blkno * 2
on 12/02/2008 17:58 Bruce Evans said the following:
> On Tue, 12 Feb 2008, Andriy Gapon wrote:
>> And the actual reading works correctly because udf_strategy is called
>> for such vnodes and it translates block numbers from physical to logical
>> and also correctly re-calculates b_iooffset for actu
bsize = DEV_BSIZE
> would be clearly wrong. Things aren't that simple (but probably should
> be). Even RELENG_3 has bsize = f_iosize (possibly != 512) for non-disks.
O, I missed this obvious thing!
Bruce, thank you for putting me back on the ground :-)
Even in UDF case, when we bread(
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
2.3. this code passes to bread blkno that is calculated as 4*sector,
where sector is a number of a physical 2048-byte sector. [**]
[**] - I think that this is a requirement of buffcache system, b
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
on 06/02/2008 18:29 Andriy Gapon said the following:
Small summary of the above long description.
For directory reading fs/udf performs bread() on a (underlying) device
vnode. It passes
on 12/02/2008 13:47 Poul-Henning Kamp said the following:
> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>
>> 2.3. this code passes to bread blkno that is calculated as 4*sector,
>> where sector is a number of a physical 2048-byte sector. [**]
>> [**] - I think that this is a requirement o
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>2.3. this code passes to bread blkno that is calculated as 4*sector,
>where sector is a number of a physical 2048-byte sector. [**]
>[**] - I think that this is a requirement of buffcache system, because
>internally it performs many calculation
on 12/02/2008 10:53 Poul-Henning Kamp said the following:
> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>> on 06/02/2008 18:29 Andriy Gapon said the following:
>>> Small summary of the above long description.
>>> For directory reading fs/udf performs
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>on 06/02/2008 18:29 Andriy Gapon said the following:
>> Small summary of the above long description.
>> For directory reading fs/udf performs bread() on a (underlying) device
>> vnode. It passes block number as if bl
on 06/02/2008 18:29 Andriy Gapon said the following:
> Small summary of the above long description.
> For directory reading fs/udf performs bread() on a (underlying) device
> vnode. It passes block number as if block size was 512 bytes (i.e.
> byte_offset_within_dev/512). On the other
on 06/02/2008 18:29 Andriy Gapon said the following:
> Small summary of the above long description.
> For directory reading fs/udf performs bread() on a (underlying) device
> vnode. It passes block number as if block size was 512 bytes (i.e.
> byte_offset_within_dev/512). On the other
MAXBSIZE; do bread via directory vnode rather than device vnode
(udf_readlblks was a macro-wrapper around bread).
udf_vfsops.c:
Hunk1 - this is borrowed from cd9660, apparently this data is needed for
correct cluster reading.
Couple of words about testing.
udf in 7.0-RC1 plus this patch correctly
file entry.
>> This is a special case that needs to be handled differently.
>> udf_readatoffset() handles it, but the latest udf_read code doesn't.
>> I have a real UDF filesystem where this type of allocation is used for
>> small files and those files can not be read.
>
on 05/02/2008 20:16 Pav Lucistnik said the following:
> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>
>>> Yay, and can you fix the sequential read performance while you're at it?
>>> Kthx!
>
>> this was almost trivial :-)
>> See the attached patch, first hunk is just for consistency.
>> Th
on 04/02/2008 17:55 Scott Long said the following:
> Andriy Gapon wrote:
[snip]
>> After some code reading and run-time debugging, here are some facts
>> about udf directory reading:
>> 1. bread-ing is done via device vnode (as opposed to directory vnodes),
>> as a cons
Andriy Gapon wrote:
on 04/02/2008 22:07 Pav Lucistnik said the following:
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
You do realise that you have now made yourself the official
maintainer of the UDF file
Andriy Gapon wrote:
on 04/02/2008 22:07 Pav Lucistnik said the following:
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
You do realise that you have now made yourself the official
maintainer of the UDF file
Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
> > Yay, and can you fix the sequential read performance while you're at it?
> > Kthx!
> this was almost trivial :-)
> See the attached patch, first hunk is just for consistency.
> The code was borrowed from cd9660, only field/variable names are
on 04/02/2008 20:36 Julian Elischer said the following:
> Andriy Gapon wrote:
>> More on the problem with reading big directories on UDF.
>
> You do realise that you have now made yourself the official
> maintainer of the UDF file system by submitting a competent
> and insig
on 04/02/2008 22:07 Pav Lucistnik said the following:
> Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
>> Andriy Gapon wrote:
>>> More on the problem with reading big directories on UDF.
>> You do realise that you have now made yourself the official
>> mainta
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
> Andriy Gapon wrote:
> > More on the problem with reading big directories on UDF.
>
> You do realise that you have now made yourself the official
> maintainer of the UDF file system by submitting a competent
> and insig
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
You do realise that you have now made yourself the official
maintainer of the UDF file system by submitting a competent
and insightful analysis of the problem?
First, some sleuthing. I came to believe that the
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
First, some sleuthing. I came to believe that the problem is caused by
some larger change in vfs/vm/buf area. It seems that now VMIO is applied
to more vnode types than before. In particular it seems that now vnodes
More on the problem with reading big directories on UDF.
First, some sleuthing. I came to believe that the problem is caused by
some larger change in vfs/vm/buf area. It seems that now VMIO is applied
to more vnode types than before. In particular it seems that now vnodes
for devices have non
More on the problem with reading big directories on UDF.
First, some sleuthing. I came to believe that the problem is caused by
some larger change in vfs/vm/buf area. It seems that now VMIO is applied
to more vnode types than before. In particular it seems that now vnodes
for devices have non
On Sun, 2 Jul 2000, Soren Schmidt wrote:
> It seems Julian Elischer wrote:
> > I am working on UDF support.
> > I have at present a program that reads a udf filesystem
> > and am working (today) on making it into an "mtools" like
> > program that allows acce
Soren Schmidt had the audacity to say:
>
> Uhm, the real value of UDF is that it can be used as a "real" rw
> filesystem on CDRW/DVDRAM media, if this is not implemented the
> value of having UDF is very limited IMHO
>
Not necessarily, since the cd9660 backwa
Soren Schmidt wrote:
>
> It seems Julian Elischer wrote:
>
> Indeed, makeing a ro UDF filesystem more or less useless :)
I will be adding read/write later..
One must be able to walk before running!
As for RO UDF, it is useful for reading UDF2.0.1 cds that don't
have ISO966
It seems Julian Elischer wrote:
> I am working on UDF support.
> I have at present a program that reads a udf filesystem
> and am working (today) on making it into an "mtools" like
> program that allows access to the contents in a useful manner.
>
> I will eventually
I am working on UDF support.
I have at present a program that reads a udf filesystem
and am working (today) on making it into an "mtools" like
program that allows access to the contents in a useful manner.
I will eventually turn this into a (readonly) filesystem, and it
is designed
It seems Coleman Kane wrote:
> Hello, is anyone currently working on code to implement the UDF
> filesystem? For those not familiar with it, it is the filesystem that
> DVDs use. I'd like to look into getting the support under FreeBSD, since
> the players already seem to w
Hello, is anyone currently working on code to implement the UDF
filesystem? For those not familiar with it, it is the filesystem that
DVDs use. I'd like to look into getting the support under FreeBSD, since
the players already seem to work. If no one is working on this, then I
could probabl
ually had an ISO9660 filesystem as well - which all
>> of my DVDs have, but which still doesn't mean that there are no
>> DVDs with only UDF, but no ISO9660 filesystem.
>
>I'm pretty sure all DVD's produced to date have an iso9660 file sys
>on them, but they
>Waht I was thinking about doing, was first writting, (probably using
the
>nullfs code a a base) a userfs, that would allow me to run most of
the
>guts of the filesystem code in a user process. Then I would write the
UDF
>filesystem to run in a user process.
>What do you think,
As I mentioned earlier, I'm thinking about trying to implement a UDF
filesystem. I've been thinking how to start and have come up with the
following, and would appreciate any comments.
Waht I was thinking about doing, was first writting, (probably using the
nullfs code a a base) a us
> Someone should do a study to find out how many human life spans have
> been lost waiting for NT to reboot.
> Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc
Hmm. Our Compaq Proliant (running NT) takes about 5 whole minutes from the
moment I click reboot to the time when I
On Fri, Jan 14, 2000 at 09:29:58AM +0100, Soren Schmidt wrote:
> It seems Brian Beattie wrote:
> > I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I
> > was wondering if anybody was working on it. I'm thinking about trying to
> > implement i
It seems Brian Beattie wrote:
> I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I
> was wondering if anybody was working on it. I'm thinking about trying to
> implement it for CD-RW's and would like to avoid duplication of effort and
> the a
I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I
was wondering if anybody was working on it. I'm thinking about trying to
implement it for CD-RW's and would like to avoid duplication of effort and
the anoyance of getting half way through the effort and
48 matches
Mail list logo
