Re: Kernel roughing in tool
2012/4/13 Alan Corey ab...@devio.us: I've just uploaded a small program I wrote for configuring a kernel based on the devices found by doing a dmesg with a generic kernel. It tries to detect Are you happy supporting CoreyBSD?
Taller Marketing Digital por Lev Castelan WSI Últimos Lugares D.F., GDL y MTY
[IMAGE] El taller mas completo de Marketing Digital en Mixico! 100% Garantma de Satisfaccisn. Un dma completo con el Coach Internacional Lev Castelan descubriendo las herramientas y la forma de hacer Marketing Digital! !Reciba la informacisn completa! Por favor responda este e-mail con los datos siguientes Empresa Nombre Telifono Email Nzmero de Interesados En breve recibira temario, reseqa de expositor y tarifas. Pms Capacitacisn Efectiva de Mixico es una empresa Registrada ante la STPS Trabajamos con expertos en la materia para poder brindar herramientas tacticas, vanguardistas y de facil aplicacisn. Si lo prefiere comunmquese a los telifonos donde con gusto uno de nuestros ejecutivos le atendera. Telifonos: (0133) 8851-2365, (0133) 8851-2741 con mas de 10 lmneas. Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Copyright (C) 2011, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. E-Mail MARKETING SERVICE POWERED BY MEDIAMKTOOLS. Este Mensaje ha sido enviado misc@openbsd.org a como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. ALTO, si en esta ocasisn la informacisn recibida no fue de su interis pero desea recibir informacisn personalizada en relacisn a otros temas favor de indicarlo. Si usted ha recibido este mensaje por error, haga caso omiso de el y de antemano una sincera disculpa por la molestia, reporte su cuenta respondiendo este correo con el subject BAJAMKT Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAMKT Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia para nosotros y no es intencisn de la empresa la inconformidad del receptor, nuestra intencisn es promover herramientas de utilidad para el [demime 1.01d removed an attachment of type image/jpeg which had a name of imageseo002.jpg]
Re: Kernel roughing in tool
So much for diversity, I guess. I find the group-think here fairly disappointing, especially as this is the general usage list and not just for OpenBSD developers. Sounds like party-member arse-licking. On Fri, Apr 13, 2012 at 8:25 AM, Martin Schrvder mar...@oneiros.de wrote: 2012/4/13 Alan Corey ab...@devio.us: I've just uploaded a small program I wrote for configuring a kernel based on the devices found by doing a dmesg with a generic kernel. It tries to detect Are you happy supporting CoreyBSD? -- joe gain jacob-burckhardt-str. 16 78464 konstanz germany +49 (0)7531 60389 (...otherwise in ???)
Re: rfork(2) considered harmful? [Re: CVS: cvs.openbsd.org: src]
On Thu, Apr 12, 2012 at 6:26 AM, Mo Libden m0lib...@mail.ru wrote: Wow. If memory serves, rfork() availability was a feature. Now it is gone... Any reasons to share please? It allowed creation of interesting types of processes, awesome flexibility regarding share of memory space and/or file handle tables. It was added in 1996, but as of OpenBSD 5.1 there were *no* programs in base and exactly *one* in ports that used it at all. That one in ports is lang/go, which will be trivially converted to use __tfork. So, rfork provided lots of awesome flexibility...which no one found a good use for. It served a good purpose by providing a hook for rthreads development, but at this point it was just increasing the complexity of the kernel. Philip Guenther
Re: Kernel roughing in tool
On Fri, Apr 13, 2012 at 12:18 AM, Joe Gain joe.g...@gmail.com wrote: So much for diversity, I guess. I find the group-think here fairly disappointing, especially as this is the general usage list and not just for OpenBSD developers. Someone suggests doing A. Doing A makes answering questions and resolving problems harder. If lots of people do A, device support will be slower and more costly. No one has started a mailing list or built a community of people that are interested in supporting people that do A. What are you proposing to do? Are you going to provide that support and assist people that do A? Or are you complaining that the other people are not volunteering to spend their time on giving that support *instead of* doing general development of OpenBSD? Is supporting other people doing A more important than what other people are doing right now? Philip Guenther
Re: Kernel roughing in tool
Alan Corey ab...@devio.us wrote: I've just uploaded a small program I wrote for configuring a kernel based on the devices found by doing a dmesg with a generic kernel. You mean like Camiel Dobbelaar's dmassage Perl script from 2002? ;-) I still keep a copy around because it can print a pretty device tree like this: root \-mainbus0 |-bios0 | |-apm0 | \-pcibios0 |-cpu0 \-pci0 |-auich0 | \-audio0 |-ehci0 | \-usb0 | \-uhub0 |-ichiic0 | \-iic0 | \-spdmem0 |-ichpcib0 | \-isa0 | |-aps0 | |-isadma0 | |-npx0 | |-pckbc0 | | |-pckbd0 | | | \-wskbd0 | | \-pms0 | | \-wsmouse0 | \-pcppi0 |\-spkr0 |-pchb0 |-pciide0 | \-wd0 |-ppb0 | \-pci1 | |-cbb0 | | \-cardslot0 | | |-cardbus0 | | \-pcmcia0 | |-em0 | |-iwi0 | \-sdhc0 |\-sdmmc0 |-uhci0 | \-usb1 | \-uhub1 |-uhci1 | \-usb2 | \-uhub2 |-uhci2 | \-usb3 | \-uhub3 \-vga1 |-intagp0 | \-agp0 |-inteldrm0 | \-drm0 \-wsdisplay0 -- Christian naddy Weisgerber na...@mips.inka.de
Re: Kernel roughing in tool
Joe Gain wrote: So much for diversity, I guess. Chaos bringing diversity is not desirable. I find the group-think here fairly disappointing, especially as this is the general usage list and not just for OpenBSD developers. The purpose of this group (list) is not the personal please of Joe Gain. You've touched a very sensible subject, called kernel tweaking. It has a long history well documented in the FAQ and the mailing list. Sounds like party-member arse-licking. Maybe for you.
Re: Kernel roughing in tool
What a waste of time. And it is well known that we don't even look at problem reports that use a custom kernel. A sore point perhaps? Still worth noting, there is sometimes a reason to modify a kernel or cut down its size, and that is why the procedure is documented on openbsd.org.
Re: Kernel roughing in tool
On 04/13/12 20:21, David Diggles wrote: What a waste of time. And it is well known that we don't even look at problem reports that use a custom kernel. A sore point perhaps? Still worth noting, there is sometimes a reason to modify a kernel or cut down its size, and that is why the procedure is documented on openbsd.org. It isn't a sore point, it's the simple fact a non-supported kernel can be a bear to work on. ...Is the problem real, or introduced by the person making the special kernel? Once off of 486's, I've never had a reason to cut down the size of a kernel. The standard bsd and bsd.mp kernels have never failed me. If you're *adding* something into the kernel, I think that would be a different story and you could get people to help you. --STeve Andre'
Re: preserving editor files
I also have the symptom reported by Jean-Frangois SIMON (misc, 177504, 8 Sept 2010): Peter N. M. Hansteen peter at bsdly.net writes: Jean-Frangois SIMON jfsimon1981 at gmail.com writes: At start-up the OS stays several minutes on preserving editor files. Could you please inform me what to do about this what is the system then doing ? Is it normal ? It's recovering vi's temporary files (from /var/tmp somewhere if memory serves), and it's a part of the normal startup sequence: peter at deeperthought:~$ sudo grep preserving /etc/* /etc/rc:echo 'preserving editor files.'; /usr/libexec/vi.recover /etc/termcap:# eyeball, the translation was correct and perfectly information-preserving. peter at deeperthought:~$ file /usr/libexec/vi.recover /usr/libexec/vi.recover: a /usr/bin/perl -w script text executable Several minutes sounds like a lot, was the last shutdown not a clean one? - P It is near 10 minutes pause in boot-up if the script has *anything* to process in /var/tmp/vi.recover/ - more than 5, closer to 10. The next thing in /etc/rc is the network daemon startup, and those diags don't appear on console or in /var/log/ until after /usr/libexec/vi.recover has waited out whatever it is waiting for. I'm running OpenBSD 5.0 (the amd release). Jean-Frangois wasn't. I see the script uses sendmail. I haven't configured that yet. ta Douglas
