Re: virtual drive errors
On Thu, 08.04.2010 at 00:50:40 +0300, Andriy Gapon wrote: Looking at cdcheckmedia and at the logged READ TOC (0x43) SCSI command errors (as reported by Markus) I see the following problem. Even if cdsize() call at the beginning of cdcheckmedia() succeeds, a subsequent failure of cdreadtoc() throws us to 'bailout' label which is past the code that sets d_mediasize. I think that the following patch should help with this situation (and possibly other cases with READ TOC problems): --- a/sys/cam/scsi/scsi_cd.c +++ b/sys/cam/scsi/scsi_cd.c [snip] This patch, much like the one in kern/138789 makes my external Plextor PX-755A drive successfully read mastered DVD media, i.e., the retail kind, not DVD-R/RW. So, please commit some version of this patch. Thanks! Regards, Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make pkg_install suite reusable, please
On Fri, 9 Apr 2010, Alexander Churanov wrote: 2010/4/9 Leinier Cruz Salfran salfrancl.lis...@gmail.com i want to ask you one thing: can you make the 'pkg_install' suite reusable .. means install 'libinstall.a' as a shared object in order to make it reusable by others devs I'd like to add my 50 cents. From my point of view, the true UNIX way is re-using whole programs. This provides unbelievable isolation and correctness. If you don't want to fork myriads of processes each second, then, it's, probably, better to ask for pipe mode of pkg_* tools. For example, aspell works that way. You start a process, write commands and queries and read results. While there are clearly benefits to process isolation, there are countless situations in UNIX where I've said to myself Oh, I wish I had a libfoo not just a foo command. This is particularly the case for monitoring tools, where third-party applications have a lot of trouble parsing and tracking the output of tools like ps(1), etc. This is why recently we've been working on libmemstat(3), libprocstat(3), libnetstat(3), etc -- so that tools can avoid rewriting that code as well as avoid the parsing problem. So I have no particular opinion on this tool, but I will say that in general, it would be nice if programs were often thin wrappers around a library that could be reused, not just command line tools. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make pkg_install suite reusable, please
On Fri, 9 Apr 2010, Charlie Kester wrote: It was a watershed moment in my programming career when I realized that the bubbles on those DFD charts we used to use for structured design could be whole processes and not just functions in a single, monolithic program. Suddenly everything the structured design folks were saying about re-use, encapsulation, loose coupling, module cohesion, etc. made a lot more sense when viewed from the perspective of simple Unix utilities communicating with plain text via pipes. We should encourage that approach as a default, and only put things into binary libraries when forced to by performance considerations. Per my e-mail, I'm not sure I entirely agree with this view, although for certain types of scripting and programming it makes a lot of sense. What was always missing from this model is a structured way to pass complex data between components: streams of one-line ASCII strings work fine, but when you want to pass data structures, you end up replicating code to generate and parse data between components. Maybe XML is an answer to this, but more likely it's not :-). There's also the issue of plugging and types: if you support complex types, why not have type checking on the plugs? For example, gzcat | tar -xf - only for certain file types: wouldn't it be nice if type information, as well as byte streams, were passed around and you could do static checking, or even negotiation. But it would be nice to get a clear typing error instead of garbage. This is, BTW, what windowing systems do for copy-and-paste: when you copy from one program and paste to another, the two programmes negotiate an appropriate intermediate format: if the target doesn't support rich text, then it needs to be generated as plain text by the source, etc. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC 2010
On Sat, 10 Apr 2010, jax wrote: I am Igor Druzhinin and I want to participate in GSoC 2010 in FreeBSD project. I want to propose to completely realise fast syscalls support for FreeBSD on x86 platform. I have already submited my proposal few days ago on GSoC site and tried to contact with possible mentors from technical contacts list. But they they still have not answered me. So I have decided to try here. What do you think about this proposal? Is it still actual or not? If so, who can be my mentor? Hi Igor-- Due to the volume of proposals, it can take some time to get through them all, and the last few weeks have been a bit rife with holidays around the world which has slowed down answers to some questions/pings. I see your proposal in the set, and I'll point some appropriate potential mentors at it this week. Thanks for your proposal! Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
I want to participate in some FreeBSD project
Hello! I am a 3rd year B.Tech (Computer Science) student. I want to participate in some open source project during my summer vacations. I thought about going the Google summer of code way but due to limited knowledge and examinations during the 1st month of the program timeline didn't participate in it. However, I still want to help with the FreeBSD projects. I understand that there will be no stipend and possibly will not be provided any mentor but I request the FreeBSD team to kindly consider me for any of their ongoing project (I might help some student selected via Google SoC). I'm no programming expert and have only a basic experience in languages like C, C++, and various scripting languages. My aim for participating in a project with a big organization like The FreeBSD foundation is to understand how programming works in real world projects and use that knowledge to be an active contributor in the open source world. If I'm rejected for whatever reason I request the members and the FreeBSD team to kindly provide me links to improve my programming in the Linux arena and hopefully make it next year in the Google SoC. Regards, Ishan Sharma I've also filled the form which FreeBSD requested the students to fill up for Google SoC (Contact details have been omitted for obvious reasons). Name: Ishan Sharma email: ishan_shar...@yahoo.co.in Availability: I'll be available after mid June. I;ll be having vacations so I can work whole day from home till mid August. After that I can spend 2-3 hrs. daily during weekdays and 4-5 hrs. or more during weekends. Bio: I'm a 3rd year B.Tech (Computer Science) student. I've only basic experience in programming languages like C, C++, Scripting languages. I've absolutely no experience of working on real projects but I'm a fast learner and if given some pointers will try to a valuable resource to the project. I know I'll need to learn a lot and that's why I'm filling out this application because if I'm not selected this year I'll be better prepared for the next year. Additionally, any help provided by the FreeBSD team now (even if it's just a link to a book I've to read) will make me a better candidate for the future. Possible Mentor: No choice. I just want to be included in a project and learn by watching others complete a project from scratch. Project Information: I just request to be included in any project which is to be started. I'll read about it as much as I can and will give a description of it and how I can help with it. Project Description: I'll research into whatever project I'm provided and will provide a description of it and how I can help with it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Unofficial Heimdal 1.1 backport from 8.0-RELEASE for 7.3-RELEASE
All, I've created a patch that will replace Heimdal 0.6.x that comes with 7.3-R base with a backported version of Heimdal 1.1 from 8.0-R and have found it useful in a couple of scenarios. This should add in AES support, among other things, without having to rely on/use ports. http://people.rit.edu/rpsfa/freebsd/heimdal-1.1_for_7.3.tgz To install: -Obtain a fresh source tree for 7.3-R -cd /usr/src patch -p0 /path/to/patch -Rebuild/install world and re-run mergemaster No warranties/guarantees; however, it has worked for me so far and I figured that I would share, -r ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make pkg_install suite reusable, please
On Sun, 11 Apr 2010 12:37:27 +0100, Robert Watson wrote: On Fri, 9 Apr 2010, Alexander Churanov wrote: 2010/4/9 Leinier Cruz Salfran salfrancl.lis...@gmail.com i want to ask you one thing: can you make the 'pkg_install' suite reusable .. means install 'libinstall.a' as a shared object in order to make it reusable by others devs I'd like to add my 50 cents. From my point of view, the true UNIX way is re-using whole programs. This provides unbelievable isolation and correctness. If you don't want to fork myriads of processes each second, then, it's, probably, better to ask for pipe mode of pkg_* tools. For example, aspell works that way. You start a process, write commands and queries and read results. While there are clearly benefits to process isolation, there are countless situations in UNIX where I've said to myself Oh, I wish I had a libfoo not just a foo command. This is particularly the case for monitoring tools, where third-party applications have a lot of trouble parsing and tracking the output of tools like ps(1), etc. This is why recently we've been working on libmemstat(3), libprocstat(3), libnetstat(3), etc -- so that tools can avoid rewriting that code as well as avoid the parsing problem. A middle-ground solution to this is to standardise on a common data exchange format with a schema definition language. With schema you can autogenerate high level parsers and generators, validators and other things for free. It does not have to be XML with XML-Schema (though there are good plaintext schema languages like RelaxNG-compact and you could possibly find less verbose text encoding for XML). Fine human readable competitors to XML exists like OGDL, YAML or JSON. OGDL project even have patches for OGDL output in GNU utlities. If, say ps or ipfw, had a switch like '--format-output-yaml' and '--print-output-schema' (alternatively schema files could be stored somewhere in $prefix/share) it would be trivial to use them anywhere. Similar approach could be adopted to input passing with possibility of pipe mode. Any utilitily, with mere tweaks to output formatting and pipe mode would in fact be a class that you could instantiate (run) and use like any other object in your programming language and all of that for free, autogenerated from schema descriptions ;) The only problem I see is agreeing on a single format and forcing everyone to use it. Which is probably why it will never happen :( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
