Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| summerofcode2008 [2008/09/09 15:31] – PrzemekWitaszczyk | summerofcode2008 [2020/02/10 09:18] (current) – Added Gsoc category TrevorRoydhouse | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | The %%FreeBSD%% Project was awarded 21 slots for student project this year, although we had many more worthy applications. | + | The %%FreeBSD%% Project was awarded 21 slots for student project |
| ====== Links to Project Pages ====== | ====== Links to Project Pages ====== | ||
| - | * [[MayurShardul/ | + | * [[MayurShardul/ |
| - | * [[NFSv4_ACLs]], | + | * [[NFSv4_ACLs]], |
| - | * [[PortsLicenseInfrastructure|Ports license auditing infrastructure]], | + | * [[Ports/ |
| * [[Porting_FreeBSD_to_Efika_(PPC_bring_up)]], | * [[Porting_FreeBSD_to_Efika_(PPC_bring_up)]], | ||
| * [[KonradJankowski/ | * [[KonradJankowski/ | ||
| Line 35: | Line 35: | ||
| **Student: | **Student: | ||
| - | **Mentor: | + | **Mentor: |
| **Summary: | **Summary: | ||
| Line 64: | Line 64: | ||
| Use of small tests. So we can cover a wide range of traffics, events and transitions predetermined separately. The development would be like a protocol, but without covering all possible events and transitions, | Use of small tests. So we can cover a wide range of traffics, events and transitions predetermined separately. The development would be like a protocol, but without covering all possible events and transitions, | ||
| - | Links: | + | Links: |
| ---- | ---- | ||
| Line 121: | Line 121: | ||
| **Summary: | **Summary: | ||
| + | |||
| + | Collation is what allows for current language/ | ||
| * imported data from the Unicode Consortium: POSIX locale files and regression test data | * imported data from the Unicode Consortium: POSIX locale files and regression test data | ||
| Line 131: | Line 133: | ||
| * for last few days I'm working on implementing expansions, I'll not rest until they work | * for last few days I'm working on implementing expansions, I'll not rest until they work | ||
| * I wasn't able to start writing manpages and create a megapatch agains HEAD, I'll do that when the algorithm is 100% correct for all the languages. | * I wasn't able to start writing manpages and create a megapatch agains HEAD, I'll do that when the algorithm is 100% correct for all the languages. | ||
| + | Current informatin will be available on my wiki: [[KonradJankowski/ | ||
| **Ready to enter CVS:** After finishing expansion support and cleanup. | **Ready to enter CVS:** After finishing expansion support and cleanup. | ||
| Line 168: | Line 171: | ||
| I was a bit late developing results because the %%SoC%% began before my exams did (I was still having classes), but now, that " | I was a bit late developing results because the %%SoC%% began before my exams did (I was still having classes), but now, that " | ||
| - | Andre Oppermann is my mentor. I blogged a bit about this project at http://blogs.freebsdish.org/ | + | Andre Oppermann is my mentor. I blogged a bit about this project at http://planet.freebsd.org/ |
| **Ready to enter CVS:** No. | **Ready to enter CVS:** No. | ||
| Line 204: | Line 207: | ||
| I intend to do further testing and benchmarking to find the best default values to use for vfs.ufs.dirhash_reclaimage (the number of seconds a dirhash can sit unused before the dirhash low memeory event handler will unconditionally delete it) and the minimum percentage of memory that will be freed upon vm_lowmem events even if there are not enough hashes older than dirhash_reclaimage (currently this is hard coded to 10%). I would also like to add some code to choose a reasonable new default vfs.ufs.dirhash_maxmem value based upon the amount of memory in the system, set automatically at boot time and tunable via sysctl. Once these tweaks have been made I plan to ask for testing from more users to shake out any bugs or potential workloads where the new code may hurt overall performance. | I intend to do further testing and benchmarking to find the best default values to use for vfs.ufs.dirhash_reclaimage (the number of seconds a dirhash can sit unused before the dirhash low memeory event handler will unconditionally delete it) and the minimum percentage of memory that will be freed upon vm_lowmem events even if there are not enough hashes older than dirhash_reclaimage (currently this is hard coded to 10%). I would also like to add some code to choose a reasonable new default vfs.ufs.dirhash_maxmem value based upon the amount of memory in the system, set automatically at boot time and tunable via sysctl. Once these tweaks have been made I plan to ask for testing from more users to shake out any bugs or potential workloads where the new code may hurt overall performance. | ||
| - | Current details about status are on the wiki here: http:// | + | Current details about status are on the wiki here: DirhashDynamicMemory |
| ---- | ---- | ||
| Line 233: | Line 236: | ||
| ---- | ---- | ||
| + | |||
| + | ===== Enhancing FreeBSD' | ||
| **Project: | **Project: | ||
| Line 285: | Line 290: | ||
| The license database (a list of them and their properties) was going to be mirrored from FOSSology: a tool to analyze software licenses. We're working on getting FOSSology to automatically classify ports (I've sent suggestions and patches to the developers, who accepted them and provided very good support). So for the moment it's not usable (at least licenses/ | The license database (a list of them and their properties) was going to be mirrored from FOSSology: a tool to analyze software licenses. We're working on getting FOSSology to automatically classify ports (I've sent suggestions and patches to the developers, who accepted them and provided very good support). So for the moment it's not usable (at least licenses/ | ||
| - | I'll continue working on the FOSSology' | + | I'll continue working on the FOSSology' |
| **Ready to enter CVS**: not yet | **Ready to enter CVS**: not yet | ||
| Line 309: | Line 314: | ||
| options added. | options added. | ||
| - | Details and usage examples are on my blog: http://blogs.freebsdish.org/gleb/ | + | Details and usage examples are on my blog: http://planet.freebsd.org/gleb/ |
| **Ready to enter CVS:** Not yet, diff is submitted to freebsd-net@ for public review. | **Ready to enter CVS:** Not yet, diff is submitted to freebsd-net@ for public review. | ||
| Line 330: | Line 335: | ||
| As for now, half of the project is realized. After solving a few difficult | As for now, half of the project is realized. After solving a few difficult | ||
| problems at the basic level (binary interface issues with entry point to the | problems at the basic level (binary interface issues with entry point to the | ||
| - | SmartFirmware on the device), the boot procedure reaches the device | + | %%SmartFirmware%% on the device), the boot procedure reaches the device |
| drivers initialization stage, and hits the PIC driver init. At this point, the driver skeleton is constructed and is called. The driver uses ofwbus bus driver which | drivers initialization stage, and hits the PIC driver init. At this point, the driver skeleton is constructed and is called. The driver uses ofwbus bus driver which | ||
| intermediates between the openfirmware and the %%FreeBSD%% newbus devices hierarchy. After completing the PIC driver, I'll be in the position to write the remaining drivers for peripherals integrated on the MPC5200B chip using the newbus architecture. | intermediates between the openfirmware and the %%FreeBSD%% newbus devices hierarchy. After completing the PIC driver, I'll be in the position to write the remaining drivers for peripherals integrated on the MPC5200B chip using the newbus architecture. | ||
| Line 337: | Line 342: | ||
| date in order to bring at least the interrupt controller driver to operation.. | date in order to bring at least the interrupt controller driver to operation.. | ||
| - | More info available at project' | + | More info available at project' |
| - | http:// | + | |
| - | and at my %%GSoC%% 2008 blog: http:// | + | |
| **Ready to enter SVN:** not yet, at least PIC driver required. | **Ready to enter SVN:** not yet, at least PIC driver required. | ||
| + | |||
| + | ===== Audit Firewall Events from Kernel ===== | ||
| + | **Project**: | ||
| + | |||
| + | **Student**: | ||
| + | |||
| + | **Mentor**: Christian Peron (csjp@) | ||
| + | |||
| + | **Summary**: | ||
| + | This project is part of %%TrustedBSD%% project and aims to provide auditing support to security-related events generated by various firewall implementations on %%FreeBSD%% such as IPFW, PF and IPFILTER. | ||
| + | |||
| + | Currently both administrative events (such as add/remove rules) and network events (such as network connection establishment) are being audited on IPFW. This means that all IPFW security-related events are already being audited the way we planned it to. Although PF and IPFILTER auditing support aren't yet finished, all the hard infrastructure work needed to implement that is already committed. | ||
| + | |||
| + | The next step is basically finish implementing PF and IPFILTER' | ||
| + | |||
| + | More information can be found here: | ||
| + | [[DiegoGiagio/ | ||
| + | |||
| + | **Ready to enter SVN:** Not determined yet, perhaps parts of it. | ||
| + | |||
| + | ===== ShinyBSD ===== | ||
| + | **Project**: | ||
| + | |||
| + | **Student**: | ||
| + | |||
| + | **Mentor**: WarnerLosh | ||
| + | |||
| + | **Summary**: | ||
| + | |||
| + | This project was a success and a failure at the same time. I started work imagining that I would be creating, genuinely creating, a new tiny operating system from %%FreeBSD%%. This was to be a worthy goal, a challenging goal, and overall a fun goal. I imagined it would involve making a bunch of shell scripts for stripping out various parts of the OS, integrate a custom kernel, and bob's your mother' | ||
| + | |||
| + | Instead, I gained respect for %%TinyBSD%%, | ||
| + | |||
| + | The second portion was to cross compile and boot an arm device. I had more hardware issues than you can shake a large stick at, so though I can verify that I was working hard on cross compiling, I cannot verify that the cross compiled product I had made sense as a bootable image. I've started configuring qemu now to see if I can verify via that. In discussion with my mentor, I believe a profitable method of applying my knowedge | ||
| + | |||
| + | **Ready to enter SVN:** Not yet, though when the Makefile is complete it would be good to offer it up for inclusion in base. | ||
| + | |||
| + | ---- | ||
| + | |||
| + | {{tag> | ||