| | 1417 | |
| | 1418 | |
| | 1419 | @node Section 5.9, , Section 5.8, Help |
| | 1420 | @section Why did you decide not to support undocumented chips? |
| | 1421 | |
| | 1422 | There are several reasons why we are generally not interested in writing |
| | 1423 | drivers for undocumented chips: |
| | 1424 | |
| | 1425 | @itemize |
| | 1426 | @item Writing a driver without a datasheet is much harder, as you have to |
| | 1427 | guess most things. Remember that, most of the time, we write drivers for fun |
| | 1428 | and for free, so there is no reason we would write a driver in conditions |
| | 1429 | that promise more pain than fun. |
| | 1430 | @item If we hit a problem, we are certain never to get any support from the |
| | 1431 | chip manufacturer. This means that we may spend days on code which will |
| | 1432 | finally never work. |
| | 1433 | @item There are several chips out there which are fully documented and lack |
| | 1434 | a driver. This is natural for us to give these the priority when we |
| | 1435 | finally have some spare time to spend on driver coding. |
| | 1436 | @item Hardware monitoring chips are not toys. Misprogramming them can |
| | 1437 | result in data loss or hardware breakage. This is obviously more likely |
| | 1438 | to happen with undocumented chips. This is a responsability we do not |
| | 1439 | want to endorse (the GPL is pretty clear than we are not legally |
| | 1440 | liable, but still). |
| | 1441 | @end itemize |
| | 1442 | |
| | 1443 | There are also several reasons why we do not want to support such drivers, |
| | 1444 | even if they were written by other people: |
| | 1445 | |
| | 1446 | @itemize |
| | 1447 | @item Problems are much more likely to happen with such drivers. |
| | 1448 | This means increased needs of support. User support if very |
| | 1449 | time-consuming and we are usually short of time. |
| | 1450 | @item Support should be done by the driver author (as only him/her knows |
| | 1451 | the driver and chip) but in the reality of facts, people will always ask |
| | 1452 | us for help if the driver is part of our package. Redirecting all user |
| | 1453 | requests to the driver's author manually is boring. |
| | 1454 | @item The lack of datasheet usually results in an original driver which |
| | 1455 | works relatively fine for its author, but will happen not to work |
| | 1456 | completely for other users. This means that the driver will need many |
| | 1457 | more additions and fixes than other drivers do, resulting in an increased |
| | 1458 | maitainance workload, which we can hardly afford. Of course this too should |
| | 1459 | be handled by the original driver author, but we never know whether he/she |
| | 1460 | will actually do the work. |
| | 1461 | @end itemize |
| | 1462 | |
| | 1463 | Lastly, there are other considerations, some of which are deliberately |
| | 1464 | political: |
| | 1465 | |
| | 1466 | @itemize |
| | 1467 | @item We do not want to trick hardware buyers into thinking that a chip is |
| | 1468 | fully supported under Linux when in fact it is only partly supported by a |
| | 1469 | driver which was written without a datasheet. Clearly stating that such |
| | 1470 | chips are not supported makes it much easier for anyone who really needs |
| | 1471 | fully working hardware monitoring under Linux to avoid motherboards with |
| | 1472 | these partly supported chips. |
| | 1473 | @item Drivers written without a datasheet are a pain for developers and |
| | 1474 | users, but are a complete win for the manufacturers of these chips: |
| | 1475 | they don't have to write the driver, they don't have to help us, |
| | 1476 | they don't have to support the users, and they still sell their |
| | 1477 | hardware. We do not want to encourage such a selfish behavior. |
| | 1478 | @end itemize |
| | 1479 | |
| | 1480 | That being said, authors of such drivers can still submit their code to |
| | 1481 | the Linux kernel folks for inclusion into Linux 2.6. Their driver may be |
| | 1482 | accepted there, under conditions. |
| | 1483 | |
| | 1484 | If such a driver is ever accepted into the Linux 2.6 tree, and someone |
| | 1485 | provides a patch to libsensors and/or sensors to add support for this |
| | 1486 | driver, we will apply it. This generic code is unlikely to cause trouble. |
| 1525 | | |
| 1526 | | @node Section 6.9, , Section 6.8, Contribute |
| 1527 | | @section How to block spam on the project mailing list |
| 1528 | | |
| 1529 | | Sorry, we know the spam is a hassle. It would be nice to have a |
| 1530 | | moderator who can screen everything, but that takes too much time and |
| 1531 | | delays emails. Right now there is a procmail script which tags likely |
| 1532 | | spam and puts in a X-SBClass: header. If it is followed by 'Spam', then |
| 1533 | | it is almost certainly spam, if it is followed by 'Blocked', then it |
| 1534 | | scores high as being potential spam. You should be able to set some |
| 1535 | | rules in your mail client to throw those emails into a seperate folder. |
| 1536 | | It's not bullet proof (some legit mails get tagged wrong, and vice |
| 1537 | | versa), but it seems to be about 95% accurate in our experience. |
