Nabble - openbsd port - ppc

全面生◆产设】备维●护如△何做●好

2009-12-01T11:58:55Z

gOj O8<{ 8= <~ Z0

[demime 1.01d removed an attachment of type application/msword which had a name of =?GBK?B?Pcz0PdW9PcHjPcvwPbrEPbyrPc/ePbXEPc7kPcb3LS1UUE0uZG9j?=]

=?iso-8859-1?Q?Le vrai Rollup =E0 prix imbattable - Offre temporaire?=

2009-11-28T12:41:09Z

Le vrai Rollup

Madame, Monsieur,

Consciente de la volonti des entreprises de relancer leur activiti
commerciale, Rollup Belgium a souhaiti s'associer ` cette dimarche en
proposant une offre exceptionnelle sur ses prix, dij` les plus bas du marchi.

64 eur par rollup ` partir de 6 pihces

Cette offre est limitie dans le temps.
Voir conditions au bas de cette newsletter **.

Principales caractiristiques

Impression digitale incluse
format de l'image: 85 x 200 cm
housse de transport comprise
upload direct de vos images
jusque 10 images diffirentes par commande

Rappelez-vous !

Offre limitie dans le temps.

(**) Conditions d'application de cette offre:
Uniquement pour les commandes passies via le site
Uniquement pour les commandes dont les visuels sont chargis via le site
(upload direct)
Date limite de validiti: dimanche 13 dicembre 2009

Rollup Belgium est une division de VTS s.a.
6041 Gosselies - Belgique
www.rollupbelgium.be

Pour vous disinscrire: envoyer un email avec UNSUBSCRIBE comme sujet `
unsubscribe@.... Merci

Re: YDL PowerStation Support

2009-10-27T09:15:30Z

> From: Ummon Karpe <ummonk@...>
> Date: Mon, 26 Oct 2009 11:07:28 -0500
>
> I am considering purchasing the YDL PowerStation:
> http://www.fixstars.com/en/products/powerstation/
>
> One of the considerations in wether I buy it or not is if I will some
> time in the future be able to install OpenBSD on it, replacing Yellow
> Dog Linux. I will be willing to compile from source if necessary.
> Looking at the specs
> (http://www.fixstars.com/en/products/powerstation/specs.html), it uses
> SLOF, which appears to be an implementation of OpenFirmware.
> Additionally, I see that the Broadcom BCM5780 seems to be a supported
> ethernet device. However, the macppc port does not claim support for
> the ATI X1650 gfx card. Is this a problem? Most importantly, though,
> the YDL PowerStation uses two dual core 2.5ghz G5 chips. If I
> interpret the supported hardware page correctly, the quad core Power
> Mac G5 is not supported. Also, does OpenBSD/macppc actually make use
> of the extra cores, or does it just utilize one core? This might be a
> dumb question, but I have only run OpenBSd on a G4 Cube, so I am not
> sure what the status of SMP support on PowerPC is.

The reason the quad core Power Mac G5 isn't supported has little to do
with the processor support. The problem is related to some weirdness
in the interrupt controller. SMP on PowerPC seems to work fairly
well; snapshots and releases are built on an SMP machine!

However, I don't think you'll be able to boot OpenBSD/macppc on that
machine. The IBM firmware is probably different enough from the Apple
firmware to require a few tweaks in the bootloader and the early
kernel bootstrapping code. Shouldn't be too difficult, but it is
still somewhat hardcore kernel hacking which won't happen unless you
do it yourself or get hardware in the hands of one of the OpenBSD
kernel hackers.

YDL PowerStation Support

2009-10-26T09:07:28Z

I am considering purchasing the YDL PowerStation:
http://www.fixstars.com/en/products/powerstation/

One of the considerations in wether I buy it or not is if I will some
time in the future be able to install OpenBSD on it, replacing Yellow
Dog Linux. I will be willing to compile from source if necessary.
Looking at the specs
(http://www.fixstars.com/en/products/powerstation/specs.html), it uses
SLOF, which appears to be an implementation of OpenFirmware.
Additionally, I see that the Broadcom BCM5780 seems to be a supported
ethernet device. However, the macppc port does not claim support for
the ATI X1650 gfx card. Is this a problem? Most importantly, though,
the YDL PowerStation uses two dual core 2.5ghz G5 chips. If I
interpret the supported hardware page correctly, the quad core Power
Mac G5 is not supported. Also, does OpenBSD/macppc actually make use
of the extra cores, or does it just utilize one core? This might be a
dumb question, but I have only run OpenBSd on a G4 Cube, so I am not
sure what the status of SMP support on PowerPC is.

Thanks for any help,
Ummon

O melhor preço The best price

2009-09-29T06:34:54Z

MAIL ERROR

[demime 1.01d removed an attachment of type image/jpeg]

[demime 1.01d removed an attachment of type image/jpeg]

Re: What's a good PCI gigabit ethernet card to use with obsdppc on G4 towers?

2009-09-28T17:41:23Z

On 19/09/2009 15:06, Ray Arachelian wrote:
> Hi,
>
> Can you recommended a decent PCI gigabit ethernet card to use with
> OpenBSD on G4 towers?
>

intel pro/1000GT?

Equipos Bonificados

2009-09-28T09:04:28Z

Personal es tu forma de comunicarte

.Porque queremos ser la empresa N01 en comunicaciones corporativas y
entendimos que para ello debmamos, no sslo tener una excelente propuesta
comercial sino que tenmamos que adaptarnos a las necesidades especificas
de cada empresa o individuo es que creamos un conjunto de planes,
herramientas y servicios que optimiza la comunicacisn entre flotas y una
fuerza de ventas y atencisn a empresas con ejecutivos altamentente
capacitados y entrenados para, junto a usted, optimizar de la mejor
manera posible sus necesidades de comunicacisn.

PLANES DISPONIBLES PARA CUIT 20 Y 30. SIN COSTOS DE INGRESO. SIN PAGO DE
EQUIPOS. SIN DEPOSITOS EN GARANTIA. $228 + Imp. por mes por 6 lmneas ($38
x lmnea) / 1080 minutos libres / 6 Samsung 1045, LG 110, Nokia 1208 s
Motorola w175 totalmente bonificados. $418 + Imp. por mes por 11 lmneas
($38 x lmnea) / 1870 minutos libres / 10 Samsung 1045, LG 110, Nokia 1208
s Motorola w175 y 1 Nokia 5310, Motorola EM28 o Motorola W396 totalmente
bonificados. $760 + Imp. por mes por 11 lmneas ($38 x lmnea) / 3700
minutos libres / 14 Samsung 1045, LG 110, Nokia 1208 s Motorola w175,
4Nokia 2760 o Motorola W388 y 2 BlackBerry, Motorola V8 o Motorola A1200
totalmente bonificados.

.Los planes Personal Grupo Business han sido creados para que usted y su
empresa estin comunicados siempre de la manera mas econsmica.Estas son
algunas de sus caracteristicas.

* Inter flota Personal: Todos los llamados dentro de su propia flota
son gratuitos e ilimitados.

* Subsidio Total de Equipos: Todos los equipos van totalmente
bonificados!!!

* Marcacion Fija: Puede bloquear algunos telifonos para que solo puedan
realizar llamadas dentro de la flota y utilizar esos minutos libres
desde otras terminales.

* Intra flota Personal: Puede elegir hasta 10 nzmeros fuera de su flota
para tambiin hablar sin cargo con ellos.

* Facturacion Desdoblada: Puede recibir una factura individual para
cada usuario en diferentes domicilios.

* Redes 3G: Los mejores abonos y servicios de internet msvil de alta
velocidad y el mejor desarrollo de la red 3G en Argentina.

* Servicios de Valor Agregado: Todos los planes tienen incluidos y sin
cargo Video LLamada, Contestador Personal, Caller ID, Mensaje
Personal, DDN, Quiin Llama?, LLamada en espera, etc.

* El Mejor Costo de Minuto de Mercado: En flotas de 6 a 10 lmneas $0.25
el minuto en el plan mas basico, en flotas de mas de 11 lmneas $0.22
el minuto (mas iva e imp.)

* Grupo Business Control: Permite la posibilidad de que una vez
consumidos el valor del abono (en llamados fuera del grupo o sms)
sslo se mantenga la comunicacisn interna, sin generar excedentes en
la factura pero el usuario pueda recargarle cridito con tarjeta.

* Windows Mobile: Es una importante herramienta de sincronizacisn de
E-Mail, Calendario, Contactos, Tareas, Notas, Etc. desarrollada,
exclusivamente, para el mercado corporativo brindandole mas
productividad al ejecutivo cuando esta fuera de la oficina.

* Facturacisn Electronica.

* Portal web exclusivo: Permite utilizar, consultar y configurar de
forma on-line los servicios contratados en las lmneas de su cuenta.

* Detalle de consumos On Line.

* Stop Personal: Servicio que permite controlar el consumo de
excedentes de las lmneas de una cuenta a travis de la restriccisn
total o parcial de los servicios de Voz, SMS, MMS y GPRS.

* Navegador Personal: El servicio Navegador Personal GPS es el primer
servicio de navegacisn satelital para telifonos celulares. Es un
servicio exclusivo de Personal, posible a travis de un acuerdo con
GARMIN (uno de los principales proveedores de esta tecnologma a nivel
internacional).

* Localizacisn Personal: Es un servicio que permite consultar la
ubicacisn geografica de lmneas Personal en todo el pams.

. Para recibir mas informacisn por favor escribanos a: consulta@...
adjuntandonos un nzmero de telifono y uno de nuestros Ejecutivos de
Cuenta se contactara con usted..

Este es un email legal, libre de virus y contiene informacisn de
servicios y productos que consideramos pueden ser de su interis De
acuerdo con la nueva Ley argentina N: 26.032, la libre distribucisn
de este email esta autorizada por tratarse de propssitos de informacisn,
sin embargo, si le hemos causado alguna molestia por el mismo, le rogamos
acepte nuestras disculpas y nos envme un mail respondiendo a este mensaje
con el asunto "REMOVER" para no ser contactado nuevamente.

Oferta valida sslo para clientes con CUIT contratando un mmnimo de 3
lmneas (entre lmneas nuevas y existentes). Los precios informados no
incluyen impuestos. Oferta sujeta a aprobacisn crediticia por
parte de Telecom Personal SA. Alicia Moreau de Justo 50; CUIT
30-63945373-8.

---

Votre Rollup à 69 eur, impression digitale incluse

2009-09-22T05:24:14Z

Le vrai Rollup

69 htva

Prix unitaire / 12 pihces

Pour
d'autres quantitis,

voir tarif digressif sur le site.

(1,3,6,12,36,96)
Offre de bienvenue

20 de remise sur

votre premihre commande (*)

Valable
jusqu'au 09/10/2009

* Voir conditions

(
"http://www.rollupbelgium.be/index.php?target=pages&page_id=promo1st" )
Impression digitale haute qualiti incluse

Dimensions de l'image: 85 x 200 cm
(base x hauteur)

Jusque 10 images diffirentes par commande

Upload direct de
vos images via le site

Housse de transport comprise

(
"http://www.rollupeurope.com" )

Pour binificier de cette action,
introduire le code coupon RLP1ST11

Un seul coupon par client.

Voir
conditions. (
"http://www.rollupbelgium.be/index.php?target=pages&page_id=promo1st" )
Rollup Belgium est une division de VTS s.a.

6041 Gosselies - Belgique
www.rollupeurope.com ( "http://www.rollupeurope.com" )

Modifier vos
donnies, ou vous disinscrire de la newsletter ( "http://fs.vedi.be" )

What's a good PCI gigabit ethernet card to use with obsdppc on G4 towers?

2009-09-19T07:06:41Z

Hi,

Can you recommended a decent PCI gigabit ethernet card to use with
OpenBSD on G4 towers?

=?utf-8?B?0JFh0LfRiyDQtNCw0L3QvdGLeCDQv2/RgmXQvdGG0LjQsNC70YzQvdGL0YUga9C70LjQtdC90YLQvtCyINC00LvRjyBC0LDRiNC10LPQviDQkdC40LfQvdC1Y2Eg0KPQt9C9YdC50YJlINC/0L7QtHBv0LHQvWVlINC/byDRgmXQuyArNzkxMzM5MTM4MzcgRW1haWw6IHByb2Rhd2V6QG1peG1haWwuY29tIEl

2009-09-01T23:12:24Z

Qnaepel dk B`q on qerh hmrepmer
a`gs d`mm{u onremvh`k|m{u jkhemrnb dk Baxeco Ahgmeq`
Ankee oodpnamn sgmaire
Reketnms: +79133913837
ICQ: 6288862
SKYPE: prodawez
EMAIL: prodawez@...

Re: boot problem on Mac G3 solved :: Q: on X11 window managers

2009-08-25T12:01:59Z

On Tue, Aug 25, 2009 at 7:29 PM, RJM<gandsnut@...> wrote:
> Miguel:
>
> Thank you, that will solve it. This does not match what is found on the
> openbsd.org page for installation instructions.

Great, good to know!

> Having gotten in to the system, now I can start X11 with startx and have
> set up a .xinitrc file. The window manager is "twm".
>
> Any suggestion on how to change this to xfce4?

Something like "pkg_add xfce4" should do the trick. But this is
something I have never done (I mean, installing xfce), so probably the
package name is wrong. Try to find the package(s) name(s) in the
packages list (in the ftp site, for example).

--
Miguel

boot problem on Mac G3 solved :: Q: on X11 window managers

2009-08-25T11:29:18Z

Miguel:

Thank you, that will solve it. This does not match what is found on the
openbsd.org page for installation instructions.

Having gotten in to the system, now I can start X11 with startx and have
set up a .xinitrc file. The window manager is "twm".

Any suggestion on how to change this to xfce4?

Regards,
Robert

On Tue, Aug 25, 2009 at 6:40 PM, RJM<gandsnut@...> wrote:
> Hello:

> Having followed closely the install and boot-up instructions, I find
> my G3 Mac will not boot OpenBSD 4.5

> Without going into firmware, the Mac boots to a small flashing graphic
> of 2 faces and a question mark on a folder icon.

> Anybody familiar with this and what might be the solution?

You _need_ to go to the firmware. From your (small) description, it
looks like you have installed it using the whole disk. Thus, all you
need to do is, in the firmware prompt, type "boot hd:,ofwboot" and it
should boot.

If you want to boot directly, in the firmware you can:

setenv auto-boot? true
setenv boot-device hd:,ofwboot

Take a look at the INSTALL.macppc file
(ftp://ftp.openbsd.org/pub/OpenBSD/4.5/macppc/INSTALL.macppc).

--

Re: Q: boot problem on Mac G3

2009-08-25T10:51:17Z

On Tue, Aug 25, 2009 at 6:40 PM, RJM<gandsnut@...> wrote:
> Hello:
>
> Having followed closely the install and boot-up instructions, I find
> my G3 Mac will not boot OpenBSD 4.5
>
> Without going into firmware, the Mac boots to a small flashing graphic
> of 2 faces and a question mark on a folder icon.
>
> Anybody familiar with this and what might be the solution?

You _need_ to go to the firmware. From your (small) description, it
looks like you have installed it using the whole disk. Thus, all you
need to do is, in the firmware prompt, type "boot hd:,ofwboot" and it
should boot.

If you want to boot directly, in the firmware you can:

setenv auto-boot? true
setenv boot-device hd:,ofwboot

Take a look at the INSTALL.macppc file
(ftp://ftp.openbsd.org/pub/OpenBSD/4.5/macppc/INSTALL.macppc).

--
Miguel

Q: boot problem on Mac G3

2009-08-25T10:40:03Z

Hello:

Having followed closely the install and boot-up instructions, I find
my G3 Mac will not boot OpenBSD 4.5

Without going into firmware, the Mac boots to a small flashing graphic
of 2 faces and a question mark on a folder icon.

Anybody familiar with this and what might be the solution?

Thanks,
GandSnut

Ahora habla sin cargo con mas de 100 numeros Claro!!!

2009-08-24T08:39:58Z

AHORA TE REGALAMOS LOS EQUIPOS Y EL ABONO!!!!!

Es Simple, Es Claro
===================

Descubrm la mejor y mas economica forma de comunicarte

Porque queremos que vos tambiin seas parte de la compaqia N01 de
comunicaciones en Amirica. Para que tengas la mas amplia cobertura, el
mejor precio y la mayor variedad de servicios. Te acercamos una promocisn
para clientes con CUIT en flotas PYME y Corporativas que no podis dejar
pasar.

Lmneas

$ Plan

Minutos Incl.

$ Min. Excedente

Minutos Totales Flota

$ Totales Flota

6

$29

110

$0.26

660

$174

10

$29

125

$0.23

1250

$290

20

$29

130

$0.20

2600

$580

Los precios no incluyen IVA .

Si sacas una flota de 6 a 9 lmneas te bonificamos el 100% de los equipos
y el 50% de una factura.

Si sacas una flota de 10 a 19 lmneas te bonificamos el 100% de los
equipos y el 100% de una factura Y 100 NUMEROS CLARO FUERA DE TU FLOTA
PARA TAMBIEN HABLAR GRATIS!!!

Si sacas una flota de 20 o mas lmneas te bonificamos el 100% de los
equipos, el 100% de una factura y la Red Privada Virtual, para la totala
dministracion de tus minutos Y 200 NUMEROS CLARO FUERA DE TU FLOTA PARA
TAMBIEN HABLAR GRATIS!!!La bonificacisn sobre la factura incluye solo los
abonos, no incluye excedentes o mensajes de texto. Beneficios de las
Flotas Claro

* Comunicacisn gratuita, libre e ilimitada entre todos los miembros de
la flota desde y hacia cualquier lugar del pams.

* Bolsa de minutos (clearing) podis repartir los minutos totales de tu
flota en los telifonos que quieras e incluso dejar parte de la flota
solo para comunicacisn interna y que no tengan consumo.

* Tarifa Plana y Nacional. No importa si llamas a un fijo o a un
celular, si es corta distancia o larga distancia. El minuto siempre
rinde lo mismo y no pagas ningun concepto de red, LDN, tierra, etc.

* Red Privada Virtual, herramienta que sirve para administrar tus
telefonos como si fueran internos de tu empresa.

* Equipos sin costo, son 100% subsidiados, es decir, Claro te los
factura a $0.01 cada uno y pasan a ser de tu propiedad. Dependiendo
de la cantidad de lmneas y el valor del plan se ajusta un Mix de
Equipos. Los equipos son todos de primera marca (Motorola, Nokia, LG,
Samsung, Sony, Alcatel, etc. dependiendo el plan y la cantidad de
lmneas varman los modelos)

* Paquetes de SMS.

* Posibilidad de bloquear telifonos para que sslo tengan comunicacisn
interna y no consuman minutos de la bolsa.

* La mas amplia cobertura Nacional e Internacional.

* Sin costos de activacisn ni de ingreso

* Internet 3G en mas de 250 ciudades de Argentina.

* El valor del minuto y del SMS mas barato de mercado.

Y todos los beneficios de ser parte de la empresa nzmero 1 de
comunicaciones en Amirica. Para recibir mas informacisn envianos un mail
con tus datos a consulta@... o respondenos este
mensaje o llamanos al 011-155-003-0857 y un ejecutivo se pondra en
contacto a la brevedad. Sabina PoliEjecutivo de CuentasClaro Argentina011
155-003-0857empresas@...

Este es un email legal, libre de virus y contiene informacisn de
servicios y productos que consideramos pueden ser de su interis De
acuerdo con la nueva Ley argentina N: 26.032, la libre distribucisn
de este email esta autorizada por tratarse de propssitos de informacisn,
sin embargo, si le hemos causado alguna molestia por el mismo, le rogamos
acepte nuestras disculpas y nos envme un mail respondiendo a este mensaje
con el asunto "REMOVER" para no ser contactado nuevamente

---

Re: Old iMac and network card

2009-08-18T10:46:05Z

On Tue, Aug 18, 2009 at 1:10 PM, Otto Moerbeek<otto@...> wrote:
> On Tue, Aug 18, 2009 at 12:59:51PM +0100, Miguel wrote:
>
>> Hi,
>>
>> I was trying to setup OpenBSD on an old iMac and not everything went
>
> a dmesg, my kingdom for a dmesg! (hint: therte are many different
> macppcs that all share the name iMac)

Ok, so here it is the dmesg. Hope it helps.

[ using 438860 bytes of bsd ELF symbol table ]
console out [ATY,RagePro_C]console in [keyboard] USB and ADB found, using ADB
: memaddr 81000000 size 1000000, : consaddr 81000000, : ioaddr
80881000, size 1000: memtag 9000, iotag 9000: width 1024 linebytes
1024 height 768 depth 8
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2009 OpenBSD. All rights reserved. http://www.OpenBSD.org

OpenBSD 4.6-current (GENERIC) #82: Mon Aug 10 19:45:23 MDT 2009
deraadt@...:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 167772160 (160MB)
avail mem = 151318528 (144MB)
mainbus0 at root: model iMac,1
cpu0 at mainbus0: 750 (Revision 0x202): 333 MHz: 512KB backside cache
mem0 at mainbus0
mpcpcibr0 at mainbus0 pci: grackle, Revision 0x40
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 0 function 0 "Motorola MPC106 PCI" rev 0x40
macobio0 at pci0 dev 16 function 0 "Apple Paddington" rev 0x00
macintr0 at macobio0 offset 0x10
mesh0 at macobio0 offset 0x10000 irq 12: 50MHz
scsibus0 at mesh0: 8 targets, initiator 7
"escc-legacy" at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 15,16
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
awacs0 at macobio0 offset 0x14000: irq 17,8,9 speaker
audio0 at awacs0
"fdc" at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 18: via-cuda, 0 targets
piic0 at adb0
iic0 at piic0
wdc0 at macobio0 offset 0x20000 irq 13: DMA
wd0 at wdc0 channel 0 drive 0: <QUANTUM FIREBALL CR6.4A>
wd0: 16-sector PIO, LBA, 6149MB, 12594960 sectors
wd0(wdc0:0:0): using BIOS timings, DMA mode 2
wdc1 at macobio0 offset 0x21000 irq 14: DMA
atapiscsi0 at wdc1 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <MATSHITA, CD-ROM CR-175, 5ADF> ATAPI
5/cdrom removable
cd0(wdc1:0:0): using BIOS timings, DMA mode 2
bm0 at macobio0 offset 0x11000 irq 42,33: address 00:50:e4:c0:f4:2a
lxtphy0 at bm0 phy 0: LXT970 10/100 PHY, rev. 1
"nvram" at macobio0 offset 0x60000 not configured
vgafb0 at pci0 dev 18 function 0 "ATI Mach64" rev 0x5c, mmio
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
ohci0 at pci0 dev 20 function 0 "Opti 82C861" rev 0x10: irq 28,
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 "Opti OHCI root hub" rev 1.00/1.00 addr 1
uhub1 at uhub0 port 2 "NEC hub" rev 1.00/1.00 addr 2
uhidev0 at uhub1 port 1 configuration 1 interface 0 "Alps Electric
M2452" rev 1.00/1.01 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes, country code 13
wskbd0 at ukbd0 mux 1
wskbd0: connecting to wsdisplay0
uhidev1 at uhub1 port 3 configuration 1 interface 0 "Logitech M4848"
rev 1.00/5.00 addr 4
uhidev1: iclass 3/1
ums0 at uhidev1: 1 button
wsmouse0 at ums0 mux 0
softraid0 at root
bootpath: /pci/mac-io/ide@20000/disk@0:/bsd
root on wd0a swap on wd0b dump on wd0b

Re: Old iMac and network card

2009-08-18T05:22:02Z

>> OK. For example, the bm networkd adapter is not working properly:
>> everything seems to be fine but shortly after the interface is
>> running, it just hangs (timeout warnings start to be sent to the
>> console). I've read the FAQ
>> (http://www.openbsd.org/faq/faq12.html#macppc) and it simply says I
>> should use an USB NIC.
>>
>> Is there some progress on the bm driver or is it just something to be
>> dropped in the near future? Is there any clear understanding of the
>> problem or the driver is just broken and no one is currently working
>> on it?
>>
>> Regards,
>> --
>> Miguel

Re: Old iMac and network card

2009-08-18T05:10:37Z

On Tue, Aug 18, 2009 at 12:59:51PM +0100, Miguel wrote:

> Hi,
>
> I was trying to setup OpenBSD on an old iMac and not everything went

a dmesg, my kingdom for a dmesg! (hint: therte are many different
macppcs that all share the name iMac)

-Otto

> OK. For example, the bm networkd adapter is not working properly:
> everything seems to be fine but shortly after the interface is
> running, it just hangs (timeout warnings start to be sent to the
> console). I've read the FAQ
> (http://www.openbsd.org/faq/faq12.html#macppc) and it simply says I
> should use an USB NIC.
>
> Is there some progress on the bm driver or is it just something to be
> dropped in the near future? Is there any clear understanding of the
> problem or the driver is just broken and no one is currently working
> on it?
>
> Regards,
> --
> Miguel

Old iMac and network card

2009-08-18T04:59:51Z

Hi,

I was trying to setup OpenBSD on an old iMac and not everything went
OK. For example, the bm networkd adapter is not working properly:
everything seems to be fine but shortly after the interface is
running, it just hangs (timeout warnings start to be sent to the
console). I've read the FAQ
(http://www.openbsd.org/faq/faq12.html#macppc) and it simply says I
should use an USB NIC.

Is there some progress on the bm driver or is it just something to be
dropped in the near future? Is there any clear understanding of the
problem or the driver is just broken and no one is currently working
on it?

Regards,
--
Miguel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-08-03T13:05:36Z

On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:

> That's all I am saying. Feel free to ignore or make "blah blah blah" noises :-)
>
> So now we can, perhaps, get back (if at all) to the man pages and what
> they are implying wrt original question.
>
> Leon.

I'm just back from vacation, so I'm late to jump in. The answer krw@
has given is right. We (and as a consequence the kernel) take the
liberty to change fields in disklabel, especially the entry for the
'c' partition.

Furthermore, there are partition specific entries used by fsck_ffs to
locate the alternate superblocks. These entries are NOT maintained for
the 'c' partition.

You might want to check the source of fsck_ffs. It contains code to
locate alternate superblocks, and that code will not work for the 'c'
partition.

As for the slighly off-topic part of the thread: if we write a
guideline into our manual page, it has a good reason to be there.
Consider the man page to be your much needed authorative source of
information.

-Otto

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-27T22:26:08Z

On 7/28/09, leon zadorin <leonleon77@...> wrote:

> How you choose to represent the behavior's definition is irrelevant
> (code or words, on paper or on screen).
>
> I am, at this stage of conversation (if one can call it such), noting
> the difference (in my opinion) between implementation and definition
> -- and whilst there are cases when code represents both of such
> concepts in one place; there are other places when there simply *must*
> be multiple implementations (i.e. a source code of a given
> app/library) of a given behavior/interface (standard) so that
> different processes/boxes/entities/etc can inter-operate with each
> other.
>
> For instance: "Hello, how are you?" whether being written by me or by
> you, on screen or on paper is still better than "AOAURRAOREAr naoe
> as10 ao" ... right?

I was, originally, a little hesitant of adding this extra note but
after some thought I might as well mention it... as it may provide
more clarity on the issue of this implementation vs definition
diversion from original question. This is only to show that, in fact,
I think we are saying common things, just in different terms.

I look at the actual ('raw') source code.

I then observe/derive a resulting behavior that such code would produce.

But I then also may want to optimize/improve the code (i.e. change it
with purposes of making the application perform better, faster, etc.)
-- but the question is: "by changing the code, some (insignificant)
aspects of the resulting behavior may change as well -- so which parts
of the resulting behavior are relied-upon/are-expected by other
applications and which fall in the 'irrelevant/insignificant or,
indeed, undefined' category"? One would need to know the boundaries of
code re-factoring when improving the *implementation* whilst still
retaining the interoperability-enabling interface/contract,
expected/*defined* behavior.

Whether such expectations (behavior definitions) are sometimes written
'inline' in the source code or in some standard publication is not the
main point really.

That's all I am saying. Feel free to ignore or make "blah blah blah" noises :-)

So now we can, perhaps, get back (if at all) to the man pages and what
they are implying wrt original question.

Leon.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-27T21:37:01Z

On 7/28/09, Marco Peereboom <slash@...> wrote:

>> Perhaps, but I am not going to enter any 'p*issing contests' of who's
>> got whose name where (besides, I am not implying to be an uber-coder,
>> but I do reserve the right to express my opinion wrt matter at hand).
>> I would like to retain the concentration on the matter discussed.
>
> Your opinion is wrong and uninteresting. The only thing you have
> expressed so far is your detachment from the real world by implying that
> some sort of retarded document written by committee retards is somehow
> important.
>

I didn't say this (although I also did not express any support for
having this general attitude towards standards as 'retarded documents
written by retards'). I think your (and others) emotions are getting
in a way of seeing the point I was making.

I am not imposing a qualitative resolution that everything which is
concerned with source code implementation must be standardized by a
committee.

You appear to have concluded that I am frowning at the fact that some
parts of the source code are somehow not committee-standardized --
this is not so.

I am simply noting (i.e. observing w/o blaming-others or anything of
such sort) that, in the absence of such (or similar) standards, any
consideration for what kernel's mood may bring in a future (e.g.
arbitrary changes of interpretation of what "entire physical disk"
equates to; ala "forward-compatibility") are not sufficient for the
arguments at hand.

In fact, I am not even suggesting that someone had made such
arguments, I was simply enumerating the reasons I thought were
relevant (and rather are easy to agree-on) when considering as to what
"kernel's mood" may be interpreted in the context of the originally
raised question (e.g. man pages implications for the disk to be
functional without any disklabel being written to it [man 5
disklabel], the reasons given for not using c partition in [man
vnconfig, caveats section] et al -- as per original email).

>>
>> > The source code _does_ define the behaviour. Exactly. Perhaps the
>> > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.
>>
>> All I was saying that it is not always the case. For example:
>>
>> the code in various http client/server applications *implements* the
>> behavior (correctly or incorrectly as it may be), but the behavior is
>> *defined* elsewhere (e.g. a standard);
>
> And in the real world all these standards are treated as guidelines.

Sure. But if such guidelines do exist -- should one not, at the very
least, attempt/strive towards meeting them (provided, of course, that
the standard/guidelines have been accepted by the implementing
community)?

We are basically starting to enter the whole discussion of viewing
what "implementation" vs "definition" mean and this was so not the
point of the original question.

Besides, I am sure you already realize, that just because one may not
be implementing the standard correctly -- it does not mean that one
should simply ignore the standard altogether.

> Anyone who has written code from a "standard" know this. This also
> means that every person on this planet would interpret language the
> same. In the open source world people can't even agree what the word
> "free" means.
>

Not every person on this planet may interpret the language the same --
but this does not mean that everyone should abandon well-defined
semantics attached to well-known words and start speaking their own
non-interoperable junk. This is even more so w.r.t.
technical/programming languages.

>>
>> similar things could be said about the code in c compiler vs the c
>> standard et al.
>
> Show me 2 compilers and I'll show you 2 compilers that don't adhere to
> the spec.

This is a bit of a moot point -- and I am sure you realize this
yourself. Not adhering to the specs does not equate to ignoring them
altogether.

>> Sometimes this may not be the case, of course, but to categorically
>> imply that 'code defines behavior' is not right in my opinion.
>
> It does. Code is absolute, words on paper are not.

How you choose to represent the behavior's definition is irrelevant
(code or words, on paper or on screen).

I am, at this stage of conversation (if one can call it such), noting
the difference (in my opinion) between implementation and definition
-- and whilst there are cases when code represents both of such
concepts in one place; there are other places when there simply *must*
be multiple implementations (i.e. a source code of a given
app/library) of a given behavior/interface (standard) so that
different processes/boxes/entities/etc can inter-operate with each
other.

For instance: "Hello, how are you?" whether being written by me or by
you, on screen or on paper is still better than "AOAURRAOREAr naoe
as10 ao" ... right?

>> On the other hand -- perhaps we differ in our understanding of the
>> term "defines". You probably implying "defines" as in "results in a
>> given behavior", I am implying "defines" more in terms of
>> standardization/documentation (i.e. outline/definition of
>> rules/behavior).
>
> blah blah blah.

:-) :-) :-) Ignoring a point and making nonsensical noises are two
different things.

>> Either way -- this only reinforces what I was saying wrt to not
>> expecting any future-compatible behavior of system and thus reducing
>> the scope of disklabel and 'c' partition arguments to the
>> "static/current" codebase behavior.
>
> Compatible with what? The c partition is the whole disk, end of
> discussion. Don't know what a committee could ever add to that.

:-) When did I ever stated that some committee should standardize this?

I was commenting on man pages and that I was unclear on how I was
reading their content (one page appears to tell me that the disk does
not *need* to have disklabel to be installed at all and that the
kernel will provide one for it 'on-the-fly'; the other page appears to
say that c partition should not be used *because* fsck will need
disklabel for sector/block-finding purposes thus implying that c
partition needs a disklabel; yet another page implies a constant
semantic guarantee that 'c' partition does represent an entire and
physical disk; and then the email appeared to tell me that kernel's
"mood" can change c partition at will)... just look at the first
couple of emails in this thread for details.

All I was doing afterward is trying to restrict the context of what is
reasonable to expect w.r.t. to "kernel's mood" changing "arbitrarily"
and how such expectations should really only be conducted in the
context of current/static codebase (as there is no standard-based
commitment to future-compatibility -- *without* stating that I
expected such a future-compatible behavior to be made available).

> In fact I do know; they'd attach some arbitrary rules to show how smart
> they are or to push some corporation's agenda. The last thing they'd do
> is push anything useful.
>
> BTW, don't believe me? Go read ACPI, SCSI & IPMI specs. Then go write
> the code. Let me know how that went.
>

It's like I am trying to talk to you about apples and you are
vigorously arguing about oranges. I am *not* disagreeing with you
about oranges.

Leon.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-27T08:04:35Z

> Perhaps, but I am not going to enter any 'p*issing contests' of who's
> got whose name where (besides, I am not implying to be an uber-coder,
> but I do reserve the right to express my opinion wrt matter at hand).
> I would like to retain the concentration on the matter discussed.

Your opinion is wrong and uninteresting. The only thing you have
expressed so far is your detachment from the real world by implying that
some sort of retarded document written by committee retards is somehow
important.

>
> > The source code _does_ define the behaviour. Exactly. Perhaps the
> > source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.
>
> All I was saying that it is not always the case. For example:
>
> the code in various http client/server applications *implements* the
> behavior (correctly or incorrectly as it may be), but the behavior is
> *defined* elsewhere (e.g. a standard);

And in the real world all these standards are treated as guidelines.
Anyone who has written code from a "standard" know this. This also
means that every person on this planet would interpret language the
same. In the open source world people can't even agree what the word
"free" means.

>
> similar things could be said about the code in c compiler vs the c
> standard et al.

Show me 2 compilers and I'll show you 2 compilers that don't adhere to
the spec.

> Sometimes this may not be the case, of course, but to categorically
> imply that 'code defines behavior' is not right in my opinion.

It does. Code is absolute, words on paper are not.

> On the other hand -- perhaps we differ in our understanding of the
> term "defines". You probably implying "defines" as in "results in a
> given behavior", I am implying "defines" more in terms of
> standardization/documentation (i.e. outline/definition of
> rules/behavior).

blah blah blah.

> Either way -- this only reinforces what I was saying wrt to not
> expecting any future-compatible behavior of system and thus reducing
> the scope of disklabel and 'c' partition arguments to the
> "static/current" codebase behavior.

Compatible with what? The c partition is the whole disk, end of
discussion. Don't know what a committee could ever add to that.

In fact I do know; they'd attach some arbitrary rules to show how smart
they are or to push some corporation's agenda. The last thing they'd do
is push anything useful.

BTW, don't believe me? Go read ACPI, SCSI & IPMI specs. Then go write
the code. Let me know how that went.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T22:14:27Z

On 7/27/09, Marco Peereboom <slash@...> wrote:

>> :-) :-) :-) relax, take a pill -- no need to get emotional.
>>
>> besides I don't think we are seeing things that much differently. I
>> didn't say you were making mistakes, but if you make krap-inviting
>> statements like "the source code *defines* the behavior" then expect
>> the likewise, albeit not-that-serious, replies.
>>
>> Besides, the code may well be acting like implementation and
>> definition in one place, so no need to take such a heated bait to my
>> light replies. I'll stop now :-)
>>
>>
>> chill -- I don't mean to get a flame-war started, peace dude :-)
>
> Wow it is sunday night and you have used up all the manager-buzzword
> speak for an entire month. What's next we have to go do some Agile
> programming while implementing Extreme Programming ideas for UML
> development that then becomes XML which we then can peruse for automated
> testing because humans should not test?

:-) :-) At least you exhibit some sense of humor :-)

I am not advocating the over-standardisation, I am merely noting that
in the absence of committed-to standards, it is futile to consider any
future-incompatible 'mood' of the kernel's behavior wrt issues
discussed (e.g. c partition). And I am also *not* advocating that one
should always strive towards any future-incompatible behavior -- only
that considering such possibilities wrt discussed 'kernel mood' would
be a moot (pun intended) point. That's all.

> If I am not VP material now I don't know what will...
>

... I don't know, tell me: "what will" ? :-)

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T22:09:04Z

On 7/27/09, Theo de Raadt <deraadt@...> wrote:

>> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> >> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> >> >> Sounds a little nonsensical to me.
>> >> >>
>> >> >> 1) for example, it would make no sense to 'shrink' the size of
>> >> >> conceptual 'whole disk' (esp. if such represents the entire
>> >> >> *physical*
>> >> >> disk as per man pages) to be less than other partitions -- so
>> >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
>> >> >> in my opinion.
>> >> >>
>> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions
>> >> >> for
>> >> >> system's (kernel or userland) behavior in future versions/releases
>> >> >> for
>> >> >> practically anything (e.g. the key-generating hash in vnconfig may
>> >> >> not
>> >> >> be guaranteed to forever remain the same; the format of system calls
>> >> >> may change/evolve, disklabel format may/may-not change, sector-size
>> >> >> may become editable, etc.)... and I am certainly not looking this
>> >> >> far
>> >> >> into the future (i.e. namely and most-likely I am considering the
>> >> >> behavior wrt current kernel w/o such being upgraded continuously).
>> >> >> In
>> >> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
>> >> >> attempts when/if differently-behaving kernel is being deployed.
>> >> >
>> >> > The source code defines the behaviour.
>> >> >
>> >> > Your words don't.
>> >> >
>> >>
>> >> Neither do yours :-) Although, some would also say that source code is
>> >> not always *defining*, but rather *implementing* the behavior (which
>> >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
>> >
>> > Oh cut the crap.
>> >
>> > krw and I have a view how it should work, and we code it.
>> > Then the code is the behaviour.
>> >
>> > Perhaps we made mistakes. Perhaps they'll be changed.
>> >
>> > But you are just spouting bullshit.
>> >
>>
>> :-) :-) :-) relax, take a pill -- no need to get emotional.
>>
>> besides I don't think we are seeing things that much differently. I
>> didn't say you were making mistakes, but if you make krap-inviting
>> statements like "the source code *defines* the behavior" then expect
>> the likewise, albeit not-that-serious, replies.
>>
>> Besides, the code may well be acting like implementation and
>> definition in one place, so no need to take such a heated bait to my
>> light replies. I'll stop now :-)
>>
>>
>> chill -- I don't mean to get a flame-war started, peace dude :-)
>
> I don't know who you are, but you do nothing. What do you do?
>
> I don't see your name on any the source code.

Perhaps, but I am not going to enter any 'p*issing contests' of who's
got whose name where (besides, I am not implying to be an uber-coder,
but I do reserve the right to express my opinion wrt matter at hand).
I would like to retain the concentration on the matter discussed.

> The source code _does_ define the behaviour. Exactly. Perhaps the
> source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.

All I was saying that it is not always the case. For example:

the code in various http client/server applications *implements* the
behavior (correctly or incorrectly as it may be), but the behavior is
*defined* elsewhere (e.g. a standard);

similar things could be said about the code in c compiler vs the c
standard et al.

Sometimes this may not be the case, of course, but to categorically
imply that 'code defines behavior' is not right in my opinion.

On the other hand -- perhaps we differ in our understanding of the
term "defines". You probably implying "defines" as in "results in a
given behavior", I am implying "defines" more in terms of
standardization/documentation (i.e. outline/definition of
rules/behavior).

Either way -- this only reinforces what I was saying wrt to not
expecting any future-compatible behavior of system and thus reducing
the scope of disklabel and 'c' partition arguments to the
"static/current" codebase behavior.

> So you shut up, loser. Just go away.
>

Ok then. Be happy, take it easy.

leon.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T20:58:14Z

> :-) :-) :-) relax, take a pill -- no need to get emotional.
>
> besides I don't think we are seeing things that much differently. I
> didn't say you were making mistakes, but if you make krap-inviting
> statements like "the source code *defines* the behavior" then expect
> the likewise, albeit not-that-serious, replies.
>
> Besides, the code may well be acting like implementation and
> definition in one place, so no need to take such a heated bait to my
> light replies. I'll stop now :-)
>
>
> chill -- I don't mean to get a flame-war started, peace dude :-)

Wow it is sunday night and you have used up all the manager-buzzword
speak for an entire month. What's next we have to go do some Agile
programming while implementing Extreme Programming ideas for UML
development that then becomes XML which we then can peruse for automated
testing because humans should not test?

If I am not VP material now I don't know what will...

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T20:23:27Z

> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
> >> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
> >> >> Sounds a little nonsensical to me.
> >> >>
> >> >> 1) for example, it would make no sense to 'shrink' the size of
> >> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
> >> >> disk as per man pages) to be less than other partitions -- so
> >> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
> >> >> in my opinion.
> >> >>
> >> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
> >> >> system's (kernel or userland) behavior in future versions/releases for
> >> >> practically anything (e.g. the key-generating hash in vnconfig may not
> >> >> be guaranteed to forever remain the same; the format of system calls
> >> >> may change/evolve, disklabel format may/may-not change, sector-size
> >> >> may become editable, etc.)... and I am certainly not looking this far
> >> >> into the future (i.e. namely and most-likely I am considering the
> >> >> behavior wrt current kernel w/o such being upgraded continuously). In
> >> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
> >> >> attempts when/if differently-behaving kernel is being deployed.
> >> >
> >> > The source code defines the behaviour.
> >> >
> >> > Your words don't.
> >> >
> >>
> >> Neither do yours :-) Although, some would also say that source code is
> >> not always *defining*, but rather *implementing* the behavior (which
> >> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
> >
> > Oh cut the crap.
> >
> > krw and I have a view how it should work, and we code it.
> > Then the code is the behaviour.
> >
> > Perhaps we made mistakes. Perhaps they'll be changed.
> >
> > But you are just spouting bullshit.
> >
>
> :-) :-) :-) relax, take a pill -- no need to get emotional.
>
> besides I don't think we are seeing things that much differently. I
> didn't say you were making mistakes, but if you make krap-inviting
> statements like "the source code *defines* the behavior" then expect
> the likewise, albeit not-that-serious, replies.
>
> Besides, the code may well be acting like implementation and
> definition in one place, so no need to take such a heated bait to my
> light replies. I'll stop now :-)
>
>
> chill -- I don't mean to get a flame-war started, peace dude :-)

I don't know who you are, but you do nothing. What do you do?

I don't see your name on any the source code.

The source code _does_ define the behaviour. Exactly. Perhaps the
source code is wrong, but it *EXACTLY DEFINES THE BEHAVIOUR*.

So you shut up, loser. Just go away.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T20:11:27Z

On 7/27/09, Theo de Raadt <deraadt@...> wrote:

>> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> >> Sounds a little nonsensical to me.
>> >>
>> >> 1) for example, it would make no sense to 'shrink' the size of
>> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
>> >> disk as per man pages) to be less than other partitions -- so
>> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
>> >> in my opinion.
>> >>
>> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
>> >> system's (kernel or userland) behavior in future versions/releases for
>> >> practically anything (e.g. the key-generating hash in vnconfig may not
>> >> be guaranteed to forever remain the same; the format of system calls
>> >> may change/evolve, disklabel format may/may-not change, sector-size
>> >> may become editable, etc.)... and I am certainly not looking this far
>> >> into the future (i.e. namely and most-likely I am considering the
>> >> behavior wrt current kernel w/o such being upgraded continuously). In
>> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
>> >> attempts when/if differently-behaving kernel is being deployed.
>> >
>> > The source code defines the behaviour.
>> >
>> > Your words don't.
>> >
>>
>> Neither do yours :-) Although, some would also say that source code is
>> not always *defining*, but rather *implementing* the behavior (which
>> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)
>
> Oh cut the crap.
>
> krw and I have a view how it should work, and we code it.
> Then the code is the behaviour.
>
> Perhaps we made mistakes. Perhaps they'll be changed.
>
> But you are just spouting bullshit.
>

:-) :-) :-) relax, take a pill -- no need to get emotional.

besides I don't think we are seeing things that much differently. I
didn't say you were making mistakes, but if you make krap-inviting
statements like "the source code *defines* the behavior" then expect
the likewise, albeit not-that-serious, replies.

Besides, the code may well be acting like implementation and
definition in one place, so no need to take such a heated bait to my
light replies. I'll stop now :-)

chill -- I don't mean to get a flame-war started, peace dude :-)

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T20:06:39Z

> On 7/27/09, Theo de Raadt <deraadt@...> wrote:
> >> Sounds a little nonsensical to me.
> >>
> >> 1) for example, it would make no sense to 'shrink' the size of
> >> conceptual 'whole disk' (esp. if such represents the entire *physical*
> >> disk as per man pages) to be less than other partitions -- so
> >> '*arbitrary* changing its [disk's] limits' is an over-generalization
> >> in my opinion.
> >>
> >> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
> >> system's (kernel or userland) behavior in future versions/releases for
> >> practically anything (e.g. the key-generating hash in vnconfig may not
> >> be guaranteed to forever remain the same; the format of system calls
> >> may change/evolve, disklabel format may/may-not change, sector-size
> >> may become editable, etc.)... and I am certainly not looking this far
> >> into the future (i.e. namely and most-likely I am considering the
> >> behavior wrt current kernel w/o such being upgraded continuously). In
> >> other words, I am perfectly happy to accept the failed 'mount/fsck'
> >> attempts when/if differently-behaving kernel is being deployed.
> >
> > The source code defines the behaviour.
> >
> > Your words don't.
> >
>
> Neither do yours :-) Although, some would also say that source code is
> not always *defining*, but rather *implementing* the behavior (which
> is standardized perhaps elsewhere)... but anyway -- potato, potato :-)

Oh cut the crap.

krw and I have a view how it should work, and we code it.
Then the code is the behaviour.

Perhaps we made mistakes. Perhaps they'll be changed.

But you are just spouting bullshit.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T20:05:20Z

On 7/27/09, Theo de Raadt <deraadt@...> wrote:

>> Sounds a little nonsensical to me.
>>
>> 1) for example, it would make no sense to 'shrink' the size of
>> conceptual 'whole disk' (esp. if such represents the entire *physical*
>> disk as per man pages) to be less than other partitions -- so
>> '*arbitrary* changing its [disk's] limits' is an over-generalization
>> in my opinion.
>>
>> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
>> system's (kernel or userland) behavior in future versions/releases for
>> practically anything (e.g. the key-generating hash in vnconfig may not
>> be guaranteed to forever remain the same; the format of system calls
>> may change/evolve, disklabel format may/may-not change, sector-size
>> may become editable, etc.)... and I am certainly not looking this far
>> into the future (i.e. namely and most-likely I am considering the
>> behavior wrt current kernel w/o such being upgraded continuously). In
>> other words, I am perfectly happy to accept the failed 'mount/fsck'
>> attempts when/if differently-behaving kernel is being deployed.
>
> The source code defines the behaviour.
>
> Your words don't.
>

Neither do yours :-) Although, some would also say that source code is
not always *defining*, but rather *implementing* the behavior (which
is standardized perhaps elsewhere)... but anyway -- potato, potato :-)

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T20:02:35Z

On 7/27/09, Theo de Raadt <deraadt@...> wrote:
>> I'd say. Anywhere does it say this? My understanding was that 'c'
>> partition depicts the entire device. If this is correct, than it's not
>> even close to describing it as 'freely changing' it's semantics as per
>> kernel's mood. Artistic perhaps, but precise... not.
>
> hey, feel free to believe whatever you want.

it's not about the belief, it's about the understanding.

>
>> I don't mind not using 'c' partition for any explicit filesystems, but
>> I don't want to do so on some ritualistic, unsupported-by-explanations
>> 'fear' but rather through explicit understanding as to why, albeit
>> customised, examples would not work (i.e. kernel-generated default
>> disklabel and only 1 ffs on disk image as per previous post of mine).
>
> yeah, looking at the code is ritualistic

my comments were *not* wrt source code, they were wrt to the
aforementioned *artistic* definition/explanation of c's partition and
it's view wrt kernel's default disklabel creation.

> Guess we should stop making it available.

I guess not :-)

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T19:01:03Z

> Sounds a little nonsensical to me.
>
> 1) for example, it would make no sense to 'shrink' the size of
> conceptual 'whole disk' (esp. if such represents the entire *physical*
> disk as per man pages) to be less than other partitions -- so
> '*arbitrary* changing its [disk's] limits' is an over-generalization
> in my opinion.
>
> 2) w.r.t. forward-compatibility, one cannot make any suppositions for
> system's (kernel or userland) behavior in future versions/releases for
> practically anything (e.g. the key-generating hash in vnconfig may not
> be guaranteed to forever remain the same; the format of system calls
> may change/evolve, disklabel format may/may-not change, sector-size
> may become editable, etc.)... and I am certainly not looking this far
> into the future (i.e. namely and most-likely I am considering the
> behavior wrt current kernel w/o such being upgraded continuously). In
> other words, I am perfectly happy to accept the failed 'mount/fsck'
> attempts when/if differently-behaving kernel is being deployed.

The source code defines the behaviour.

Your words don't.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T18:57:51Z

> I'd say. Anywhere does it say this? My understanding was that 'c'
> partition depicts the entire device. If this is correct, than it's not
> even close to describing it as 'freely changing' it's semantics as per
> kernel's mood. Artistic perhaps, but precise... not.

hey, feel free to believe whatever you want.

> I don't mind not using 'c' partition for any explicit filesystems, but
> I don't want to do so on some ritualistic, unsupported-by-explanations
> 'fear' but rather through explicit understanding as to why, albeit
> customised, examples would not work (i.e. kernel-generated default
> disklabel and only 1 ffs on disk image as per previous post of mine).

yeah, looking at the code is ritualistic

Guess we should stop making it available.

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

2009-07-26T18:48:04Z

On 7/27/09, Kenneth R Westerback <kwesterback@...> wrote:

> On Mon, Jul 27, 2009 at 11:11:21AM +1000, leon zadorin wrote:
>> On 7/27/09, Kenneth R Westerback <kwesterback@...> wrote:
>> > On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote:
>> >> Man page for mount_vnd states:
>> >> "
>> >> The `c' partition of a vnd image should not be used. When a superblock
>> >> becomes damaged, fsck_ffs(8) needs information contained in the
>> >> disklabel
>> >> to determine the location of alternate superblocks. This
>> >> information
>> >> is
>> >> not available when directly using the `c' partition, so checking
>> >> the
>> >> file
>> >> system image will fail.
>> >> "
>> >>
>> >> Also, the man page for newfs states:
>> >> "
>> >> Before running newfs or mount_mfs, the disk must be labeled using
>> >> disklabel(8). newfs builds a file system on the specified special
>> >> de-
>> >> vice, basing its defaults on the information in the disk label.
>> >> "
>> >>
>> >> But... the man 5 disklabel states:
>> >> "
>> >> Note that when a disk has no real BSD disklabel the kernel creates a
>> >> de-
>> >> fault label so that the disk can be used.
>> >> "
>> >>
>> >> And indeed, it would appear (or may be my brain is getting sleepy)
>> >> that, running newfs on a device (such as svnd0c or vnd0c) which has no
>> >> disklabel installed explicitly does work ok...
>> >> ... now -- if, as man page for mount_vnd states, fsck_ffs needs
>> >> disklabel info when superblock is damaged -- why would it have any
>> >> trouble getting the default label that kernel creates for the "disk"
>> >> automatically as per man 5 disklabel quote above (the very same info,
>> >> I presume that newfs uses when initializing the fs initially on an
>> >> image with no explicit label)?
>> >>
>> >> For example, wrt alternate superblock issues during fskc, the man page
>> >> for newfs says:
>> >> "
>> >> -S sector-size
>> >> The size of a sector in bytes (almost never anything
>> >> but
>> >> 512). Changing this is useful only when using newfs
>> >> to
>> >> build
>> >> a file system whose raw image will eventually be used
>> >> on
>> >> a
>> >> different type of disk than the one on which it is
>> >> initially
>> >> created (for example on a write-once disk). Note that
>> >> chang-
>> >> ing this from its default will make it impossible for
>> >> fsck(8)
>> >> to find the alternate superblocks if the standard
>> >> superblock
>> >> is lost.
>> >> "
>> >>
>> >> Now, if the default disklabel (created by kernel, on the fly so to
>> >> speak) provides info for the sector size (which is used by newfs
>> >> during initializing, and by fsck when checking/restoring/fixing, the
>> >> fs) then why would it still be bad to use the "c" partition of
>> >> svnd/vnd?
>> >>
>> >> Kind regards
>> >> Leon.
>> >
>> > 'c' is a special partition that the kernel freely changes as the
>> > mood hits it. A slight exaggeration.
>>
>> I'd say. Anywhere does it say this? My understanding was that 'c'
>> partition depicts the entire device. If this is correct, than it's not
>> even close to describing it as 'freely changing' it's semantics as per
>> kernel's mood. Artistic perhaps, but precise... not.
>>
>> I don't mind not using 'c' partition for any explicit filesystems, but
>> I don't want to do so on some ritualistic, unsupported-by-explanations
>> 'fear' but rather through explicit understanding as to why, albeit
>> customised, examples would not work (i.e. kernel-generated default
>> disklabel and only 1 ffs on disk image as per previous post of mine).
>>
>> leon.
>
> 2nd paragraph of disklabel(8):
>
> disklabel supports 15 configurable partitions, `a' through `p', excluding
> `c'. The `c' partition describes the entire physical disk, is automati-
> cally created by the kernel, and cannot be modified or deleted by
> disklabel.

To me it sounds precise-enough (i.e. 'describes the *entire*
*physical* disk' vs "special partition that the kernel freely changes
as the mood hits it" is not a slight difference in description).

> Feel free to use 'c' for anything you want. Just don't complain, or expect
> short shrift when you do, if it blows up later on because the kernel is

:-) I don't recall expressing any complaints or having any short
shrift expectations. In fact, all I am doing is trying to understand
the internals/actual behavior model in a more intimate way.

> making free use of it by arbitrarily changing its limits to reflect a
> new concept of 'whole disk'.

Sounds a little nonsensical to me.

1) for example, it would make no sense to 'shrink' the size of
conceptual 'whole disk' (esp. if such represents the entire *physical*
disk as per man pages) to be less than other partitions -- so
'*arbitrary* changing its [disk's] limits' is an over-generalization
in my opinion.

2) w.r.t. forward-compatibility, one cannot make any suppositions for
system's (kernel or userland) behavior in future versions/releases for
practically anything (e.g. the key-generating hash in vnconfig may not
be guaranteed to forever remain the same; the format of system calls
may change/evolve, disklabel format may/may-not change, sector-size
may become editable, etc.)... and I am certainly not looking this far
into the future (i.e. namely and most-likely I am considering the
behavior wrt current kernel w/o such being upgraded continuously). In
other words, I am perfectly happy to accept the failed 'mount/fsck'
attempts when/if differently-behaving kernel is being deployed.

leon.

Nabble - openbsd port - ppc

全面生◆产设】备维●护如△何做●好

=?iso-8859-1?Q?Le vrai Rollup =E0 prix imbattable - Offre temporaire?=

Re: YDL PowerStation Support

YDL PowerStation Support

O melhor preço  The best price

Re: What's a good PCI gigabit ethernet card to use with obsdppc on G4 towers?

Equipos Bonificados

Votre Rollup à 69 eur, impression digitale incluse

What's a good PCI gigabit ethernet card to use with obsdppc on G4 towers?

=?utf-8?B?0JFh0LfRiyDQtNCw0L3QvdGLeCDQv2/RgmXQvdGG0LjQsNC70YzQvdGL0YUga9C70LjQtdC90YLQvtCyINC00LvRjyBC0LDRiNC10LPQviDQkdC40LfQvdC1Y2Eg0KPQt9C9YdC50YJlINC/0L7QtHBv0LHQvWVlINC/byDRgmXQuyArNzkxMzM5MTM4MzcgRW1haWw6IHByb2Rhd2V6QG1peG1haWwuY29tIEl

Re: boot problem on Mac G3 solved :: Q: on X11 window managers

boot problem on Mac G3 solved :: Q: on X11 window managers

Re: Q: boot problem on Mac G3

Q: boot problem on Mac G3

Ahora habla sin cargo con mas de 100 numeros Claro!!!

Re: Old iMac and network card

Re: Old iMac and network card

Re: Old iMac and network card

Old iMac and network card

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

O melhor preço The best price