|
|
 Up |
|
|
  |
Author: Danny BranissDanny Braniss
Date: Jul 10, 2006 22:19
> Maxim Sobolev wrote:
>
>> Scott Long wrote:
>>
>>> David O'Brien wrote:
>>>
>>>> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
>>>>
>>>>> I was thinking of doing something like that. You can basically
>>>>> get the same info by doing something like:
>>>>> file - < /dev/ad0s1e
>>>>> /dev/stdin: Unix Fast File system (little-endian)
>>>>> file - < /dev/ad0s4
>>>>> /dev/stdin: SGI XFS filesystem
>>>>>
>>>>> I leaned away from this approach in mount(8) because:
>>>>> - I didn't want to tie mount(8) to file(1)
>>>>
>>>>
>>>> ...
|
| Show full article (1.43Kb) |
|
| |
no comments
|
|
|
Author: Scott LongScott Long
Date: Jul 10, 2006 18:36
Maxim Sobolev wrote:
> Scott Long wrote:
>
>> David O'Brien wrote:
>>
>>> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
>>>
>>>> I was thinking of doing something like that. You can basically
>>>> get...
|
| Show full article (1.21Kb) |
|
| |
no comments
|
|
|
Author: Maxim SobolevMaxim Sobolev
Date: Jul 10, 2006 18:13
Scott Long wrote:
> David O'Brien wrote:
>> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
>>
>>> I was thinking of doing something like that. You can basically
>>> get the same info by doing something like:
>>> file - < /dev/ad0s1e
>>> /dev/stdin: Unix Fast File system (little-endian)
>>> file - < /dev/ad0s4
>>> /dev/stdin: SGI XFS filesystem
>>>
>>> I leaned away from this approach in mount(8) because:
>>> - I didn't want to tie mount(8) to file(1)
>>
>>
>> Why not? We have libmagic for purposes like this.
>>
>
> This is an interesting idea. However, it has the potential to
> add a dependency on /usr to the early boot environment. Maybe it ...
|
| Show full article (1.02Kb) |
|
no comments
|
|
|
Author: Scott LongScott Long
Date: Jul 10, 2006 17:41
David O'Brien wrote:
> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
>
>>I was thinking of doing something like that. You can basically
>>get the same info by doing something like:
>>file - < /dev/ad0s1e
>>/dev/stdin: Unix Fast File system (little-endian)
>>file - < /dev/ad0s4
>>/dev/stdin: SGI XFS filesystem
>>
>>I leaned away from this approach in mount(8) because:
>>- I didn't want to tie mount(8) to file(1)
>
>
> Why not? We have libmagic for purposes like this.
>
This is an interesting idea. However, it has the potential to
add a dependency on /usr to the early boot environment. Maybe it
could be done via rtld?
|
| Show full article (0.88Kb) |
|
no comments
|
|
|
Author: David O'BrienDavid O'Brien
Date: Jul 10, 2006 15:43
On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote:
> I was thinking of doing something like that. You can basically
> get the same info by doing something like:
> file - < /dev/ad0s1e
> /dev/stdin: Unix Fast File system (little-endian)
> file - < /dev/ad0s4
> /dev/stdin: SGI XFS filesystem
>
> I leaned away from this approach in mount(8) because:
> - I didn't want to tie mount(8) to file(1)
|
| |
|
no comments
|
|
|
Author: Christoph HellwigChristoph Hellwig
Date: Jul 10, 2006 13:41
On Mon, Jul 10, 2006 at 02:30:20PM -0600, Scott Long wrote:
>>lead to all kinds of funnies. Linux does this (iterating all filesystem
>>types in kernel) for the special case of the root filesystem where mount(8)
>>is not available, and it showeds various interesting bugs at least in the
>>fat driver.
>>
>
> How does it resolve situations like with UDF vs iso9660, where both
> structures can co-exist?
The kernel doesn't do anything fancy. It just walks the list of filesystem
and the first fs that takes it gets it. To answer the specific example
iso9660 is registered before udf so if you wanted to use a dual-fs cdrom
as root you would get iso9600 unless you specified the rootfstype=udf
boot option.
_______________________________________________
freebsd-arch@ freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@ freebsd.org"
|
| |
|
no comments
|
|
|
Author: Scott LongScott Long
Date: Jul 10, 2006 13:33
Christoph Hellwig wrote:
> On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
>
>>So in your opinion and experience, what are the pros and cons of
>>maintaining a table of magic numbers?
>
>
> The feature is imensely useful. The implementation won't win any
> points for a clean design but works very well in practice. I think
> it's definitly better than probing in the kernel because letting a filesystem
> driver try to make sense of something that's not it's own format can
> lead to all kinds of funnies. Linux does this (iterating all filesystem
> types in kernel) for the special case of the root filesystem where mount(8)
> is not available, and it showeds various interesting bugs at least in the
> fat driver.
>
How does it resolve situations like with UDF vs iso9660, where both
structures can co-exist?
Scott
|
| Show full article (1.05Kb) |
|
no comments
|
|
|
Author: Andrew ThompsonAndrew Thompson
Date: Jul 10, 2006 13:28
On Mon, Jul 10, 2006 at 09:04:41AM -0700, Brooks Davis wrote:
> On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote:
>> Sam Leffler wrote:
>>>I committed the revised netif cloning api so you can now specify
>>>parameters when cloning. I also modified the vlan code to use this
>>>mechanism so doing something like:
>>>
>>>ifconfig vlan create vlan 1 vlandev em0
>>>
>>
>> /me wants to do:
>>
>> "ifconfig em0.1 inet 192.168.2.2/24"
>>
>> Even simpler. And yes, this works already but only if if_vlan.ko
>> was loaded before or compiled into the kernel. It doesn't do auto-
>> load. >
> Unless cause ifconfig to autoload all if_ modules when cloning fails,
> it's impossiable to support this without having if_vlan loaded. That ...
|
| Show full article (1.38Kb) |
|
no comments
|
|
|
Author: Christoph HellwigChristoph Hellwig
Date: Jul 10, 2006 13:24
On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
> So in your opinion and experience, what are the pros and cons of
> maintaining a table of magic numbers?
The feature is imensely useful. The implementation won't win any
points for a clean design but works very well in practice. I think
it's definitly better than probing in the kernel because letting a filesystem
driver try to make sense of something that's not it's own format can
lead to all kinds of funnies. Linux does this (iterating all filesystem
types in kernel) for the special case of the root filesystem where mount(8)
is not available, and it showeds various interesting bugs at least in the
fat driver.
_______________________________________________
freebsd-arch@ freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@ freebsd.org"
|
| |
|
no comments
|
|
|
|
|
|
Author: Craig RodriguesCraig Rodrigues
Date: Jul 10, 2006 12:31
On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote:
> So in your opinion and experience, what are the pros and cons of
> maintaining a table of magic numbers?
One con: every time you add a new filesystem, you need to update
mount(8). Not a big deal, but it is something.
For Linux, the mount program usually is part of the util-linux
package which is separate from the kernel. util-linux and kernel
are maintained by separate groups in Linux....it is the responsibility
of the Linux distribution to bundle together versions of util-linux
and kernel that work together.
For FreeBSD, the direction I have been going is to try
to make mount(8) as simple and generic as possible, and
push all the stuff for doing filesystem specific things into
the kernel, i.e. into vfs_mount.c for generic stuff, and
into each specific filesystem for fs-specific stuff.
|
| Show full article (1.13Kb) |
|
no comments
|
|
|
|
|
|
|
