Date: Wed, 26 Feb 2014 22:19:49 -0800 (PST) From: Nomad Esst <noname.esst@yahoo.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-drivers@freebsd.org" <freebsd-drivers@freebsd.org> Subject: Writting eeprom Message-ID: <1393481989.22330.YahooMailNeo@web162704.mail.bf1.yahoo.com>
next in thread | raw e-mail | index | archive | help
We want to add our own ID for each of our modules (pci cards), is it possible to write this ID on somewhere of the card like EEPROM? Thanks in advance From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 09:34:34 2014 Return-Path: <owner-freebsd-hackers@FreeBSD.ORG> Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03E16808 for <freebsd-hackers@freebsd.org>; Thu, 27 Feb 2014 09:34:34 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.95]) by mx1.freebsd.org (Postfix) with ESMTP id D981211C1 for <freebsd-hackers@freebsd.org>; Thu, 27 Feb 2014 09:34:33 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type; b=f3eUPGrYG21zsptdqLE9wImOhWuByohNxwZMmMj/mpL5/DSD5+Fn4f/R7O0sjhkk3iJnE/zlTaCb ZxTLHETBc3powovvW4uRpNn+Tc+Q4VFei6oghx8LkSBDdFpZeErP Received: from [192.168.1.110] (194.42.110.4 [194.42.110.4]) by mx.zohomail.com with SMTPS id 1393493672391339.89314150528014; Thu, 27 Feb 2014 01:34:32 -0800 (PST) Message-ID: <530F06A7.3090005@zoho.com> Date: Thu, 27 Feb 2014 10:34:31 +0100 From: =?ISO-8859-2?Q?=A3ukasz_W=F3jcik?= <lukasz.wojcik@zoho.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: GSoC proposal: Quirinus C library (qc) References: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com> <530E3B09.2060602@zoho.com> <CAGwOe2ZVXqyJL7uKHHyS6-NwiQa7d5tDjQ-kOSLaZmeJj8v7nA@mail.gmail.com> In-Reply-To: <CAGwOe2ZVXqyJL7uKHHyS6-NwiQa7d5tDjQ-kOSLaZmeJj8v7nA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 27 Feb 2014 09:34:34 -0000 W dniu 2014-02-26 21:02, Fernando Apesteguķa pisze: > On Wed, Feb 26, 2014 at 8:05 PM, £ukasz Wójcik <lukasz.wojcik@zoho.com>wrote: > >> W dniu 2014-02-25 09:24, Dmitry Selyutin pisze: >> >> Hello everyone! >>> >>> My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State >>> University of Russia. This message is addressed mainly to C connoiseurs, >>> yet I think other people may find it interesting. It's a GSoC proposal. >>> It's a pity that for language like C we generally don't have something >>> universal like Boost, so we have to implement some common functions from >>> scratch or introduce new dependencies. We have Glib, which is used mainly >>> by Gnome developers (though it is a standalone library) and LGPL-ed, which >>> is not as liberal as Boost's license. We also have APR, which seems to be >>> a >>> bit more comprehensive and convenient, yet it is not so well-known as >>> Glib. >>> I'm in process of implementing a something like Boost for ANSI C (though I >>> don't pretend this library to share Boost's comprehensiveness). Several >>> ideas I find useful are: >>> >>> 1. Strict and universal interface. Each function begins with qc_ prefix, >>> followed by type if function is type-related. Most of types (except >>> enum-typedef'ed ones) have three common functions (replace _type_ with the >>> necessary type name, e.g. _bytes_): >>> a. Constructor: void * qc_type_construct(void). Allocate object >>> instance >>> and initialize it to default value. >>> b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory >>> allocated for object and its members. >>> c. Replicator: void * qc_type_replicate(void const * pointer). >>> Replicate >>> object, copying its data to new allocated object, i.e. clone. >>> Most of types also have _import_ and _export_ functions, which allow to >>> fill allocated object with the desired data (e.g. fill bytes array from >>> null-terminated char string) or export data to another type. Almost all >>> enum-typedef'ed types also have _import_ and _export_ functions to >>> retrieve >>> a key value corresponding to string. >>> >>> 2. Common and universal error type, qc_error. Such errors can be generated >>> from errno values as well as from Windows API errors. >>> Almost all functions from qc library except for the three common functions >>> (constructor, destructor, replicator) return qc_error code and set >>> specific >>> qc_errno variable to this code. >>> It is now possible to write such constructions: >>> if (qc_bytes_import_str(bytes_instance, "Hello, world!")) >>> qc_errormsg(qc_errno, "error check"); >>> Global variable qc_errno is implemented in terms of multithreading >>> applications, it is unique for every running thread. >>> >>> 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs >>> types for characters, where qc_byte has exactly 8-bit width and qc_ucs has >>> exactly 32-bit width). >>> Charsets are just enumeration, e.g. QC_ENCODING_UTF8, >>> QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired >>> encoding using qc_encoding_import. If encoding is known under several >>> names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be >>> returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US", >>> etc. Register doesn't matter. >>> Two new types, qc_bytes and qc_unicode are provided, in order to store >>> binary and Unicode data. It is possible to store null characters inside >>> such objects. It is similar to C++ string and C++ vector classes. >>> >>> 4. Universal file system path type. It is possible to achieve >>> cross-platformness using such path types, i.e. it is possible to make >>> directories, links, symlinks, remove files, directories, etc. regardless >>> of >>> platform path API. >>> >>> 5. i18n support must be embedded with qc library. Locales, timezones, day >>> and months names, etc. must be provided too, in several forms if >>> necessary. >>> i18n functions work with qc_unicode type, so charset conversion problems >>> won't exist. >>> >>> 6. Multithreading support if platform permits it. On POSIX we use >>> pthreads, >>> on Windows we use its API for multithreading. I'm also thinking about >>> green >>> threads implementation. Thread local storage is already implemented, yet >>> there is still a lot work to be done with threads, mutexes, etc. >>> >>> 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm >>> planning to switch to something BSD-like or to implement it from scratch >>> (that probably would be better, since library doesn't introduce any >>> dependencies except GMP). >>> >>> 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, >>> I've started this library as implementation of ternary logic operations. >>> When I've realized that there is still much to be done in other fields, >>> I've already concluded that ternary logic is suitable for a wide set of >>> other operations, e.g. comparison, determining type of strings, >>> endianness, >>> etc. I think that I'll leave type qc_trit, since I've found it extremely >>> useful. >>> >>> 9. A lot of other things to be done, such as unified I/O streams which >>> provide compression/transformation filters, protocols, math library, etc. >>> >>> >>> Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD >>> highly >>> needs such library, since we try to use BSD-like license and yet to >>> implement things that exist in GNU world. The most common example is GNU >>> readline library, yet I think there is a lot of libraries that we >>> reimplemented just to let some projects suit BSD philosophy. We can make a >>> good library, which can be used a lot in different projects, yet it will >>> field everyone like Boost. The nature of C language itself helps us to >>> keep >>> this library much more tiny than Boost library; I also think that we can >>> limit our support with POSIX-(almost-)compatible platforms and Windows. >>> >>> I've already done a lot of work, but it is hard to make decisions without >>> advice or discussion, so I've thought about to enter GSoC this year like I >>> did two years ago when I've reimplemented gnulib-tool for FSF. This >>> project >>> is much more interesting for me, since I want to upgrade my C skills, get >>> known BSD world better and provide a good cross-platform library which may >>> be useful to almost everyone. Since I've already finished my volunteer's >>> job in Sochi (I've worked as technologist volunteer), I'm really want to >>> make something new for other people to be useful. >>> >>> If you are interested in my project, here is repository at GitHub: >>> https://github.com/ghostmansd/quirinus. I guess I'll later rename it to >>> https://github.com/ghostmansd/qc, yet it doesn't matters. If you're >>> interested in my previous GSoC work, you can find it here: >>> https://github.com/ghostmansd/gnulib-python. If you want to get to know >>> me >>> better from any side (my philological studies in Lomonosov Moscow >>> University, GSoC participation, Sochi volunteer job, etc.), you can write >>> me a email; I'd be very glad. >>> >>> Thanks for reading such a long letter! >>> >>> >> Hi Dmitry, >> >> I'd like to say I personally like the idea of having glibc counterpart in >> FreeBSD (and possibly other OSes). It's not quite sure though whether >> you're looking for help with development or review ? Perhaps with something >> else ? >> > > I suppose you mean _glib_ instead of glibc (our glibc counterpart is our > libc in base). > > The project sounds nice although a lot of features (like the error > treatment, multithreading support...) are already present in glib (and they > are very well tested). > > Cheers. Yes, of course, I meant glib. As you know it's much much more feature rich than standard libc, e.g. xml parsing, regular expressions, key-value parsers and many, many more. > > >> >> Sincerely, >> -£W >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1393481989.22330.YahooMailNeo>